Reviewing Test Case

The main reason of reviewing test cases: increase test cases quality and therefore product quality.

As we know testers are involved (should be 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).

Requirement Traceability
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.

Review by User or Developer?
Of course having a "Requirements-Usability" person reviewing test cases adds a lot of value to the validity of test cases. (Here, we are talking about developing system test cases or user acceptance test cases). The problem is that this process is often overlooked due to lack of resources and organizing reviews with the potential users or user representatives, instead test case reviews would progress only with the developer involved on the same project and functionality. As we know very well, testers and developers have different mindsets and look at testing with different views. Although the developer can give useful information to the tester designing test cases, such as which areas of the software are more complex or which parts have been directly affected by a code change, they should never guide testers in writing test cases or tell the testers how a particular function should be tested, that is the job of the tester alone! Therefore, a review by the developer would find more technical issues whereas a review by the user or user representative would find more functional / usability issues.
The more pragmatic approach would be to have the test cases reviewed by a peer, possibly more experience and senior tester before sending the test case document for review to any other role (developer or user).

Benefits of having test case reviews

• Defect prevention while reviewing Requirements: SQA tester could gain knowledge of the application plus spot any ambiguity / unclear statements in requirement document before any code being developed.
• 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 such as Quality Center
• Defect prevention while reviewing test cases: If the developer has the opportunity to check the test cases while implementing code, it is possible that this will help him to realize codes that may cause potential defects.

After having the test cases reviewed, the SQA team receives all the feedback and decides, based on experience and knowledge on Software Testing and QA, and also on the functionality if comments have been applied or not. When not applied, the reason should be explained and discussed with the developer since there should be a final agreement with all stakeholders on the requirements and consequently on the test cases written.