In my Don’t Give Test Cases To N00bs post I tried to make the argument against writing test cases as a means to coaching new testers. At the risk of sounding like a test case hater, I would like to suggest three contexts that may benefit from detailed test cases.
These contexts do not include the case of a mandate (e.g., the stakeholder requires detailed test cases and you have no choice).
- Automated Check Design: Whether a sapient tester is designing an automated check for an automation engineer or an automation engineer is designing the automated check herself, detailed test cases may be a good idea. Writing detailed test cases will force tough decisions to be made prior to coding the check. Decisions like: How will I know if this check passes? How will I ensure this check’s dependent data exists? What state can I expect the product-under-test to be in before the check’s first action?
- Complex Business Process Flows: If your product-under-test supports multiple ways of accomplishing each step in its business process flows, you may want to spec out each test to keep track of test coverage. Example: Your product’s process to buy a new widget requires 3 steps. Each of the 3 steps has 10 options. Test1 may be: perform Step1 with Option4, perform Step2 with Option1, then perform Step3 with Option10.
- Bug Report Repro Steps: Give those programmers the exact foot prints to follow else they’ll reply, “works on my box”.
Those are the three contexts I write detailed test cases for. What about you?