One-page test strategy template
A test strategy is the standing agreement about how quality is judged on a product. If it does not fit on a page, it will be written once and not opened again.
Draft it yourself, then walk it block by block with the Engineering and Product leads. The disagreements in that session are the reason to have it. Review it every quarter.
TEST STRATEGY — <product> Valid for: <quarter> Product and cadence <surfaces: web, apps, APIs, back office> <sprint length, release frequency> 1. MUST STAY TRUE The journeys that carry revenue, compliance or trust. Re-checked every release. - <journey> - <journey> - <journey> 2. HOW WE LEARN WHAT CHANGED - <QA in refinement for every story> - <release diff read with the tech lead> - <who lists configuration and third-party changes, and when> 3. EVIDENCE BEFORE RELEASE - <core journeys exercised on which environment, browsers and devices> - <automated checks that run on every build> - <readiness note: who writes it, when, who reads it> 4. HOW DEFECTS GET DECIDED - Severity: <scale, link> - Triage: <how often, who attends> - Rule: <no defect open longer than N sprints without an owner and a decision> 5. DEFERRED, WITH RISK - <what is not tested> — owner: <name> — review: <date> - <what is not tested> — owner: <name> — review: <date> Agreed by: <QA lead, Head of Engineering, Head of Product> Next review: <date>
Free to use and adapt. No sign-up, no attribution needed.
How to use it
- Start with block 1. If the three leads cannot agree the journeys that must stay true, nothing else in the strategy will hold.
- Block 5 is what makes it honest. Every strategy leaves things out; this one says which, and who agreed.
- Tools and test types belong in a separate note if they are needed at all. The strategy is about decisions.
- You can tell it is in use when someone quotes it in a planning or release conversation.
Terms used here: Test strategy, Test plan, User journey.