Test Case Design - Do's and Don'ts

Any good and complete testing is as good as its test cases, since test cases reflect the understandability of the test engineer over the application requirements. A good test case should identify the yet undiscovered errors in testing.

The Do’s:
1. Identify test cases for each module
2. Write test cases in each executable step.
3. Design more functional test cases.
4. Clearly identify the expected results for each test case
5. Design the test cases for workflow so that the test cases follow a sequence in the web application during testing. For example for mail applications say yahoo, it has to start with a registration process for new users, then signing up, composing mail, sending mail etc.
6. Security is high priority in web testing. Hence document enough test cases related to application security.
7. Develop a trace ability matrix to understand the test case coverage with the requirements

The Don’ts
1. Do not write repetitive UI test cases. This will lead to high maintenance since UI will evolve over due course.
2. Do not write more than one execution step in each test case.
3. Do not concentrate on negative paths for User acceptance test cases if the business requirements clearly indicate on the application behavior and usage by the business users.
4. Do not fail to get the test cases reviewed by individual module owners of the development team. This will enable the entire team to be in the same line.
5. Do not leave any functionality uncovered in the test cases unless and until if it is specified in the test plan as features not tested.
6. Try not to write test cases on error messages based on assumptions. Document error message validation test cases if the exact error message to be displayed is given in requirements.