Test Case Review Process & Tips

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.