What belongs in a one-page test strategy, and what should be left out?
answer
- Standing choices only, one per line
- Ask whether the next release would change it
- Every line must be arguable
- Link to live sources, never copy them
- Levels, environments, automation, tooling, ownership
basics
~20 sA one-page test strategy states standing decisions: which test levels run, the stance on environments and test data, the automation stance, sanctioned tooling classes, and who owns quality. Leave out release scope, dates, staffing and anything already recorded elsewhere.
solid answer
~50 sKeep to standing decisions, one per line, each stated firmly enough that someone could disagree with it. The five lines that earn their place are: **which test levels run** and what each is trusted to catch; **the stance on environments and test data** - real dependencies or stand-ins, and where data comes from; **the automation stance** - what is automated and what stays deliberately manual; **tooling policy** - which classes of tool are sanctioned so teams do not each shop alone; and **who owns quality**, including whether anyone outside the team verifies. Everything else goes: release scope and dates belong in a plan, and any fact that lives in another system - the environment inventory, the defect list, the pipeline definition - should be linked, never copied, because copies rot silently. The test for each line is simple: if the next release could change it, it is not strategy.
go deeper
Be ready to name three things a strategy states - which test levels run, the automation stance, who owns quality - and one thing it never states, such as the release date.
Expect to sort sample lines into strategy or plan on the spot and to justify each with the same test. Interviewers often hand you a bad excerpt and ask what you would delete.
Demonstrate that you have cut an inherited document down and survived the conversation: which sections you deleted, which you replaced with links, and how you kept the remaining decisions accurate afterwards.
Argue about how many of these documents an organisation should hold and at what granularity - one per product line, one per department - and what the duplication costs when the same five decisions are restated eleven times.
## Why one page Length is not a virtue in this document. A strategy is read on a joiner's first week and consulted when someone asks where a new kind of check belongs; both readers are looking for a decision, not for prose. The discipline of one page forces every sentence to be a decision that somebody could act on or argue with. A twelve-page strategy usually contains the same five decisions plus eleven pages of tutorial material about testing in general, which is where the rot starts. ## The five lines that earn their place **1. Which test levels are used, and what each is trusted to catch.** This is the load-bearing line. It might read: fast isolated checks on every commit, integration checks across the service boundary, one end-to-end path per critical journey, and a timeboxed exploratory pass before release. The value is not the list; it is the *trusted to catch* clause, because it tells a reader where a newly discovered defect class should be checked in future. **2. The stance on environments and test data.** The strategy states the position - verified against stand-ins for third-party dependencies, with data generated rather than copied from production, say. How those environments are provisioned and how the data is produced is a different discipline and a different document; the strategy just takes the line and links out. **3. The automation stance.** Not a percentage target, but a rule someone can follow: for example, every defect that escapes to production gets a permanent automated check, and exploratory work is never automated. Whether a specific candidate check is worth automating is judged elsewhere; the strategy sets the default. **4. Tooling policy.** Which *classes* of tool are sanctioned - a scenario runner, a mocking library, a load generator, a coverage tool - and who decides when a team wants something outside the list. Naming classes rather than products keeps the line honest as products come and go, and the point of the line is to stop five teams independently adopting five stacks. **5. Who owns quality.** Whether the delivery team owns verification end to end, whether anyone outside the team verifies before release, and who is accountable when something escapes. This line resolves more arguments than the other four combined and is the one most often left out. ## What must not be in it - **Per-release facts**: scope, dates, staffing, deliverables. They belong in the plan and they will drag the strategy into constant rewriting. - **Copies of other systems**: environment inventories, defect lists, pipeline configuration, test-case listings. Link to the live source. A copy is correct on the day it is pasted and wrong within weeks, and the reader has no way to tell which. - **Tutorial content**: a definition of what integration testing is. If the team needs that, it belongs in training material, not in a document read for decisions. - **Non-decisions**: 'we will test thoroughly at every level', 'quality is everyone's responsibility' as a slogan with no ownership attached. If nobody could disagree with a line, it is decorative. A useful test: could a reasonable engineer have written the opposite? If not, delete it. ## A worked example A 4-person team owning an airline seat-map service keeps a strategy of exactly five lines. Levels: isolated checks and cross-boundary checks on every commit, one end-to-end seat-selection journey nightly, a half-day exploratory pass before each release. Environments and data: verified against a stand-in for the reservation dependency, with generated passenger records only. Automation: any defect that reaches production earns a permanent check at the lowest level that could have caught it - which is how the intermittent timeout on roughly 2.7% of seat-map reads ended up with a check at the boundary rather than in an end-to-end scenario. Tooling: the scenario runner already in the pipeline; anything new needs an argument. Ownership: the team owns quality; nobody outside it signs. What that team inherited was a 31-page document from a previous programme, of which perhaps four pages held decisions and the rest described a process the organisation had abandoned. Cutting it was not vandalism - it was the only way to make the remaining decisions visible. ## Keeping it honest Give the page a date and a named owner, and review it when the way of working changes rather than on a calendar tick. When a line no longer matches practice, either change the line or change the practice - a strategy that states something the team has stopped doing is worse than no strategy, because it gets cited in reviews and in onboarding by people who assume it is true.
- How specific should the line about which test levels run actually be?Specific enough to place a new check without asking anyone: name each level, say when it runs, and say what it is trusted to catch. Stop before it becomes a tutorial - no definitions of the levels, no example cases, no tool syntax. Roughly one sentence per level is the right size, and the trusted-to-catch clause is the part that does the work.
- How would you decide in five seconds whether a sentence belongs in the strategy or the plan?Ask whether the next release could change it. Dates, scope, names and deliverables all change per release, so they are plan content. Levels, stances, tooling policy and ownership hold across releases, so they are strategy content. If a line genuinely sits on the boundary, put it in the strategy and let the plan record the deviation when a delivery departs from it.
- What do you do when the strategy states a stance the team no longer follows?Fix it in the same week you notice, in one direction or the other: amend the document to describe what the team now does, or hold the team to the line it agreed. Leaving the mismatch is the worst outcome, because joiners and reviewers act on the written version and the gap between document and practice quietly widens until nobody trusts the page at all.
saying these in an interview costs you the question
- Copies environment setup steps into the strategy
- Lists individual test cases in a strategy document
- States a tooling wish list instead of a decision
- Puts the coming release's dates in the strategy
- Writes principles so vague nothing is actually decided
- Defines testing terms instead of making choices