Best for
- Changes big enough that 'I clicked around' is not evidence
- Agreeing what tested means before the deadline argues otherwise
- Handing testing to someone who did not build the thing
What you give it
- The change: spec, diff or description — and what the system did before
What you get back
- The verification list: every behaviour this change promises, as checkable cases
- The regression list: what this change could plausibly break, prioritised by blast radius
- Per case: level (unit/integration/manual), data needed, steps, expected result
How it works
- Derives verification cases from the change's promises — each acceptance criterion becomes testable cases including its edges.
- Derives regression cases from the change's touch points: what shares code, data or flow with what changed.
- Assigns each case the cheapest level that honestly proves it, marking what is automated versus manual.
- Specifies data and environment needs upfront, so testing does not stall on 'I need an account with…'.
Example
You: Plan the testing for our new 'pay by invoice' checkout option.
Result: 31 cases: 12 verifying the new path (including the credit-limit refusal and the tax edge), 11 regression (card checkout untouched, totals unchanged, emails still correct), 8 negative (expired credit terms, the double-submit, the browser back-button). Each with level, data setup and expected result — the two cases needing production-like data flagged for the staging pass.
Limits — please read
- A plan scopes the testing; executing it is the work that follows (yours, or a test-running agent's).
- Exploratory testing finds what plans cannot imagine; the plan reserves time for it rather than replacing it.
- Coverage is honest, not exhaustive: it says what is deliberately untested and why.