Hi Sandeep,

The role varies a little from organisation to organisation and from project
to project. For example, some Software Quality Analysts will be involved in
helping to form the requirements, in others they may only be involved in
writing test cases from requirements they have been given. In some projects
they may be sat working alongside the developers, involved in the unit
tests, in others they may be sat in a remote location, looking at release
candidates. Some may be involved in coding automated test scripts, other may
only ever run previously prepared manual test cases. That said, here are the
two absolute basic, bread and butter, day in day out roles;

Preparation and execution of test cases: This involves the ability to read
and understand both functional and non-functional Requirements, as well as
be able to spot what is not written down. It requires that the analyst is
able to think what is most likely to cause the system to fail, and then
devise a test to induce that failure,

Raising of incident records accurately and with sufficient information to
enable developers to understand and reproduce the incident. It is important
to remember that the only reason for raising a bug is so that others can
understand what the problem is. Vague, half explained and poorly constructed
bug reports are totally unacceptable.

I hope this helps

Below is an example Job Description for a tester;

To prepare and execute test cases as directed by the Lead Tester.
The testing will apply to all project deliverables, including code,
documentation, JCL , Procedures, Operational Controls, end user standards
adherence such as Common User Access and Common Look and Feel, Operational
standards such as JCL rules, job construction rules, recovery rules and
guidance documentation standards.

Overall Responsibilities
. To support the Lead Tester and Project Manager in building and
managing the test plan if required to do so.
. Perform all tasks allocated by the Lead Tester and ensure they are
completed on schedule and to budget.
. To understand and work towards achieving quality objectives.
. To communicate status against plan as and when required.

Specific Responsibilities
. Ensure all items personally produced within the test plan have
complied with the required quality assurance process, and that all have
received sign off by the appropriate organisations.
. Develop test cases as directed by the Lead Tester.
. Execute test cases as allocated by the Lead Tester.
. Raise incident records accurately and with sufficient information to
enable developers to understand and reproduce the incident.
. Ensure valid to invalid ratio of incident closing codes against
incidents personally reported is within acceptable boundaries e.g. the
number of ‘Duplicate bugs’ or ‘No Bugs’ reported is not excessive.

Competencies
. Team Working. Demonstrate positive team-working with colleagues,
works with clear accountability of own work within a team, escalates issues
promptly and reports progress
. Flexible Approach. Capable of working in a new environment, quick
learner and open to new ideas and processes
. Business Knowledge. Is analytical and has a systematic approach to
problem solving with some experience of a similar / relevant business
environment.
. Technical Knowledge. Technical Expert - provides an authoritative
view of the technical impact of change, provides technical expertise to the
test team.
. Adaptable. Proactive within the test process, can apply existing
business or technical skills to new technologies and processes quickly and
efficiently.
. Motivation. Self motivated.

Regards

Tony

Tony Simms MBCS CITP
Principal Consultant
Roque Consulting

To view the newsletter, please click here

If I understand your situation correctly, your QA team is part of a development team of 80 employees. You currently have 5 team members and you are asking for 5 more QA leaders and 5 more testers to bring your total to 15.

The typical ratio is 20 to 25% (Kit, 1995) which means that you need to have one tester for every three or four programmers. Microsoft’s ratio is 50% which means that they have one tester per programmer (Cusamano and Selby, 1998).

Given that the current number of employees in the development team is 80, you should have about 16-20 staff who should be doing QA- and testing-related work. I am aware that asking for 50% will be challenging. With the 10 additional staff that you are requesting, the development team total will go up to 90 which will give you about 17% if you raise your QA staff count to 15. You will still be on the low end but it will be much better than your current situation at 6%. Be aware that all of the number that I provided to you should be adjusted depending on the maturity of your organization (e.g., developers actually perform unit and integration testing so that testers can focus on system testing, etc.).

1 Write a full report as to why you need more resource (you dont have to show anyone the report, it is mainly to help you be clear in your own thinking). Valid reasons include (amongst others), bugs in the wild because not enough time to test properly, system failures due to not having the right skill set. Simply not having enough time to test is not necessarily a reason for more testers (it might be a reason to do less testing).

2 You need to start collecting metrics that show the value of what is being done i.e.

• How many bugs are found at what severity before release

• How many after,

• What is the cost of live Bugs to the company (If there is no real

cost then no point testing)

• Cost of down time

• Cost of rework

3 No point automating unless there is a clear reason to. Document your overall test strategy (if you have not yet done so) and detail how automation fits in, the cost and the potential return on investment.

4 Sometimes management listen to outsiders where they dont listen to their own staff, even when they say the same things. It might be worth getting a consultant in to do a strategic review and make recommendations.

Unfortunately, we dont have a lot of historical data with regards to the testing efforts for comparative purposes between normal/traditional testing versus testing in an Agile environment. However, in terms of actual tasks, there are some common similarities and differences.

In the traditional V-model approach, you will have different people doing different tests (e.g., Developers should be doing unit and integration testing; professional testers will most likely perform system testing and some sort of bridging between integration testing and acceptance testing. Lastly, the users will conduct the acceptance tests). You still need to perform these tests in an Agile environment but they need to be performed more often because of short, frequent iterations.

In contrast, there is a greater need for automated regression (no new defects were introduced) and confirmation (ensure that fixes worked) testing cycles. In one of my clients, they run these tests automatically overnight as part of their daily builds.