From http://www.softwaretestingtimes.com/2010/06/test-case-review-process-tips.html
The main reason of the reviewing test cases: increase test coverage and therefore product quality.
As
we know testers are involved on the Requirements Specification review
process to provide the SQA knowledge to the requirements written. As
testers are involved on the process they become experts on the area and
on the application functionality and many times their knowledge helps
avoid introducing future defects into the functionality that later the
developer will code (it’s the phase that we called: defect prevention).
Once
the requirements are approved and baselined, testers start designing
test cases whether on their mind, or writing them (test drafts). Once
all the ideas or test case drafts are understood and prepared, the SQA
tester will start developing test cases. When this happens, each test
case written is based on a specific requirement, so with that we start assuring having traceability between requirement and test cases. This will help SQA team to manage the Requirements coverage of what is going to be tested.
Once
the test cases are developed, SQA tester should
share-distribute-discuss those with the same team that reviewed the
requirements (SRS writer, Developers, SQA tester, Implementation team,
etc). However, sometimes this is not possible, as perhaps when
the Requirements are baselined, the person who is in charge of the SRS
starts on another project and has not even more time to dedicate
reviewing a set of test cases. The same happens with the Implementations
team, as they are perhaps installing the product on a customer site.
There are cases where SQA tester and developer start more or less at the
same time with their work based on the Requirements. Developer starts
developing code and Tester developing test cases. There are other times
that SQ Tester starts thinking or having test case drafts even before
the Developer starter coding. That means that developing code and test cases are and should be separate processes.
Of
course that having a Requirements-Usability people reviewing test cases
has a lot of value, also having the implementations team doing the
same. The problem has been that these often did not happen due the lack
of resources, so the test cases review would progress only with the
developer involved on the same project and functionality. In any case
the developer review test cases
always would go in the direction of adding details, parameters or
circumstances not included in the tester written test cases or well even
adding new test cases but never modifying the sense of the test cases
written by the tester.
This is the approach and the how the test
cases defined by testers need to be reviewed by the developer. We should
also notice that some times when the test cases writer is a beginner,
not a senior tester, or well does not have so much knowledge about the
functionality, then someone from the SQA team with more experience
should check the test cases before sharing them with the developer for
review.
Benefits of having test cases reviews for SQA test cases written, including on them the developers:
• Defect prevention while SRS review: SQA tester could advance during SRS reviews possible issues before any code starts
• Conceptual and Technical Coverage:
Requirements- Usability ensures the coverage from the Concept point of
view and Developer ensures the coverage from the Technical Point of
view. The traceability coverage track is assumed by traceability tools
(Quality Center)
• Defect prevention while test cases review:
If the developer has the opportunity to check the test cases while
implementing code, it is possible that this will help him to realize
codification that may be a cause of a defect. This will help to coding
in the way of potential defects.
• Developer Knowledge add to test cases:
Developer has also a very good understanding of the requirement (SRS),
explicit and implicit as well. Also has done a deep analysis of them
since he had to accomplish the SRA. He can bring experience on
understanding better details or well some cases not being considered.
After
having the test cases reviewed, the SQ team receives all the feedback
and decides, based on its experience and knowledge on SQA and also on
the functionality if feedback is applied or not. When not applied, the
reason should be explained and discussed with the developer since there
should be a final agreement on the test cases written.