Testing Explained for Development Managers: Test Cases
Managers: Don't overvalue the role of test cases in testing.
Test cases are not required to test software properly. Forcing detailed test cases on your testers is a considerable waste of time that pushes out your project schedule. Furthermore, monitoring test cases is a terrible way to evaluate testing progress or preparedness.
Writing test cases are only one optional testing technique for reducing risk.
Test cases can be in-depth and take a long time to prepare, or very brief. In-depth test cases can include numbered procedural steps, test setup or teardown activities, reference materials, and objective summaries. Brief test cases can be as simple as a single sentence.
When should a tester create in-depth test cases:
- External regulators require detailed test logs to show proof of software behavior.
- They are part of product delivery for the User Acceptance team.
- They support the retesting of a complicated defect.
When should a tester create brief test cases:
- You want to direct some non-testers to help with testing.
- Using them to introduce new testers to the software.
- The tester is using them to organize test coverage.
Some other common assumptions to challenge:
"All the test cases are written before testing begins."
Testing will uncover errors in requirements, missing requirements, assumptions, deviation of the implementation from the design, and more. These discoveries will result in more test cases, and testers will even need to delete some.
"Testers will always precisely follow the test case steps the same way."
People are terrible at following directions. As a result, it's rare for even a detailed tester to be able to run test cases exactly as they were written. And different testers will notice different bugs during the test run.
"The number of test cases tells you something about the completeness of testing."
The quantity does not give you an indication of the quality of tests. It doesn't help you understand the coverage or remaining risks.