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?
4 comments:
Subscribe to:
Post Comments (Atom)
RSS
Agree. Especially on "Complex Business Process Flows".
These kind of software may not be changed frequently, so we don't need to rewrite the test cases everyday :)
I really like your 3rd point :-P
In consecutive test cycles when we have to have a checkpoint to ensure we are not missing out on scenarios..we can refer testcases.This again come under coverage basically(Your second point).
But when we take a real time scenario when we run multiple tests in our head(brain)how can we b really sure that we tested everything on the product by the end of the test cycle.Just Curious!
3 is never a problem for me, I just write the repro steps detailed in-plece.
But a few cases more:
1) Compliance in some industries (airspace, health).
2) Acceptance tests (at least sometimes) - as a software builder you sometimes want to get your main chunk of money not risking, that client will find "bugs" and claim, there are too many to pay now. Just define reproducible detailed steps just for the purpose of making software accepting (and paying) process less agile :-)