Srilu Pinjala, PNSQC
Does the QUANTITY of test cases parallel to QUALITY of the test cases and compliment testing?
Issues with test cases:
- Most companies have vague test cases or no test cases.
- Test Data, environment not stated in test cases, the tester has to guess these conditions.
- Test steps are vague with multiple actions stated in one step.
- Expected result description is vague or null with no GUI changes described.
- No way to figure out which modules / flows / pages / components have test cases.
- No way to measure the completeness of a test case.
- Focusing only on the requirement and testing with a tunnel vision.
- Redundant test cases costing more time and money but adding no value as per testing.
- Adding more test cases to increase count for each requirement introduced.
We will look at typical test case examples. Identify what they lack. We will rewrite them as scenario based test cases with sufficient verification. We will work to understand and establish verification criteria for Software in general and for each product in particular. We will learn to write test cases that are robust, reusable, recyclable and ready for automation. We will learn to write QUALITY test cases.
- The test case belongs to the product.
- Test steps are of two kinds – for Testing and for navigation
- Test steps are user actions on a graphical user interface with test set up and re-setup
- Expected result are the changes on the Graphical user interface not user perception.
- Do one thing at a time, stop cramming.
- Increase Scenario based test cases with complete flows
- Reduce redundant actions and increase actual tests
- Organize test cases based on application components / modules.
- Write it once, and Write it accurately.
This paper introduces the concept that the test case should belong to the product not the requirement. The method coerces the tester to think outside the box to make the product consistent and to maybe fix the requirement too.
Target Audience: CLASS