Test case review process

Test case review process is an important process to follow in software testing. Test case ensures that each and every functionality mentioned in Software Requirement Specification is covered. Test case should be effective and also follow the standards to write test case. To success and completeness of any test cases every test case should be reviewed. There are different types of test case review process.

Test Case Reviews can be done in three ways:

1.    Self-review: It is done by the tester himself who has written the test cases. He can verify whether all the requirements are covered or not by looking into SRS/FRD.

2.    Peer review: It is done by another tester who hasn’t written those test cases but is familiar with the system under test. Also known as Maker and Checker review.

3.    Review by a supervisor: It is done by a team lead or manager who is superior to the tester who has written the test cases and has great knowledge about the requirements and system under test.

Some of the common mistakes which are check during the test case review process are:

1.    Spelling mistakes: Sometimes, spelling mistake can create a lot of confusions or make a sentence difficult to understand.

2.    Grammar: If grammar is not proper then test

3.     case can be interpreted in a wrong way, resulting in wrong results.

4.    Template format: If proper template is followed then it becomes easy to add/modify test cases in future and test case plan looks organized.

5.    Standard/Guidelines: While review process, it is very important to check whether all the standards and guideline are properly followed.

6.    Language used: Test cases should have a very simple language which is easy to understand.

7.    Functionality coverage: It is highly recommended that all the functionality associated with the system under test should be covered so that major defects are not missed.

8.    Replication: It refers to the duplicate test cases removal. It is possible that two or more test cases test the same thing and can be merged into one, this would save time and space.

9.    Redundancy: It refers to uselessness of a test case due to change in requirements or some modifications. Such test cases must be removed.

After checking all the above points, reviewer notes down all the changes/modifications required. Now, either he can have a discussion/meeting with the tester or he can send him the mail with the changes noted so that tester can go through them and make all the necessary modifications.

Points to remember/Tips while reviewing test cases:

1.    While reviewing test case, it is better to have a copy of SRS/FRD with you for the reference.

2.    If you are not sure about any test case or expected result, it is better to discuss with the client or your supervisor before making any decision.

3.    If possible then try to execute test cases on the SUT (System Under test) to have a better understanding of the results and execution steps.

4.    It is always better to have a face to face meeting with the tester to make him understand all the review feedback properly.

5.    It is recommended to follow version numbers in review process. For e.g. if you have reviewed a test case plan for the first time then make it v.1, after tester has made all the changes then after re review, the version would be v.1.1. In this way you will have a better idea which one is the latest and also you will have all the record of the changes made to the plan.