How to review Software Test Cases better?

Test cases are one of the most widely used test artifacts in software testing activity. More often than not they decide the effectiveness of the testing efforts. With test cases playing such an important role, it becomes necessary to ensure that test cases are effective, precise, and optimized. This is when a test case review process helps. As soon as test cases get written, the software QA tester should first perform a self review, and then pass it to his colleagues for a peer review, before getting it included in the test suite for execution. Read on as to how a software QA tester can perform better self review and peer review of test cases.

• Utility Value: The first thing to review in a test case is its utility value. Is this test case required? Is this testing something which has already been covered in some other test case? Is this testing something too little? There has to be definite value which this test case provides. And it should test a requirement or feature which is mentioned in the specifications of the system.
• Test Case Objective: When you go through the test case for review, check if you are able to understand the objective of the test case. A good test case should have a single objective. In case there are multiple objectives that are being tested, then you should recommend that the complex test case be broken down into more simple test cases.
• Pre-Requisites: Does the test case require any special setup to be done before execution? Is there any action to be taken before-hand? Has this been mentioned clearly in the test case?
• Steps: Does the test case contain step wise instructions to be followed for executing the test case? Can a new tester attain the objective by following the test steps? If not, then the test case writer is presuming some steps, and has missed to put in the necessary steps in the test case.
• Inputs: The test case should clearly specify what values to be given as inputs in the test case. Nowhere should it have instructions mentioning, enter any number, or string, as that may cause the test case to return different results every time.
• Language: The language used in the test case should be simple and unambiguous. There should be no scope for interpreting the test case in any other manner except the desired one.
• Results: A good test case should clearly mention what is the expected result and behaviour of the system. Determination of whether the test passes or fails should be fairly straight forward.
• Clean-up: If the test case has changed the state of the system in such a way that subsequent test cases may get affected, then it should have steps which undo these changes to ensure there is no impact on the subsequently executing tests.
• Dependencies: Does this test case have any dependencies with any other test cases? Are they to be executed before or after this test case? If yes, this too needs to be clearly documented in the test case. Ideally every test case should have its own individuality with no dependencies on others. Where it cannot be avoided, then it should be documented very clearly.
• Documentation: A test case should clearly mention the name of the author, the test case priority (if applicable), and the specific requirement which it tests so as to help in doing traceability to find out the test coverage.

Want a simple test case review checklist / template for your use? Use the following Software Test case Review Checklist .