What is the difference between a test strategy document and a test plan?
answer
- Two documents, two different lifespans
- One is standing, one is per-release
- How we test versus this delivery
- Levels and stance versus scope and dates
- One strategy sits above many plans
basics
~20 sA test strategy is standing and general: which test levels run, the stance on environments and data, the automation stance, tooling policy, who owns quality. A test plan is per-release: scope, schedule, staffing, deliverables, risks, sign-off.
solid answer
~50 sThe two documents answer different questions and live on different clocks. The **test strategy** is standing and general: which test levels the organisation runs and what each is trusted to catch, the stance it takes on environments and test data, how far it automates, what tooling classes are sanctioned, and who owns quality. It changes when the way of working changes, perhaps twice a year. The **test plan** is bound to one delivery: what is in scope, the schedule, who does the work, what is delivered, the risks carried and who signs off. It dies when the release ships. One strategy normally sits above many plans, so a plan does not repeat the strategy - it cites it and records any deliberate deviation. The common failure is one fat document that mixes both, so per-release facts drag the standing decisions into constant churn and nobody trusts either half.
go deeper
Be ready to state the difference in one sentence and name one real section from each document. Recalling that the strategy is standing and the plan belongs to a single release earns most of the mark here.
Expect to explain why the split exists - the two documents have different readers and change at different rates - and to sort a given sentence into the right one without hesitating.
Show that you have kept both alive on a real delivery: how deviations from the strategy were recorded, what you cut from an inherited plan when the date moved, and how you stopped the two documents contradicting each other.
Own the question of how many strategies the organisation should have at all, and what it costs when every team writes its own. Be ready to argue for merging or deleting a document rather than defending a template.
## Two documents, two clocks Almost every team that writes anything down about testing ends up with two kinds of statement mixed together, and the interview question exists because most candidates have only ever read one of them. The cleanest way to separate them is to ask of every sentence: *would this change if the next release were different?* If yes, it is plan material. If no, it is strategy material. A **test strategy** is standing and organisation- or product-wide. It fixes: - **Which test levels are used** - unit, integration, contract, system, acceptance, end-to-end - and what each level is trusted to catch. This is the single most load-bearing line, because it tells a reader where to add a check for a new defect class. - **The stance on environments and test data** - whether verification runs against real dependencies or stand-ins, and where data comes from. The strategy states the position; provisioning them is somebody else's document. - **The automation stance** - how far the organisation automates and what it deliberately keeps manual. - **Tooling policy** - which classes of tool are sanctioned (a scenario runner, a load generator, a coverage tool) so every team does not shop independently. - **Who owns quality** - whether the delivery team owns it end to end or a separate group verifies and signs. A **test plan** is bound to one release or one project. It fixes scope (what is being verified this time), schedule, staffing, deliverables, the risks the delivery is carrying, and who signs off. Every one of those is worthless three months later, which is exactly why they must not be welded into the strategy. ## Lifespan, audience and cadence The strategy is read by people joining a team, by an architect deciding where a new check belongs, and by anyone auditing how the organisation works. It should survive several releases untouched; if it is being rewritten every fortnight, per-release content has leaked into it. The plan is read by the people running this delivery and by whoever must accept the outcome. It is edited constantly while the delivery is live and archived afterwards. Because one strategy sits above many plans, the plan should *cite* the strategy rather than restate it, and record only the places where this delivery deliberately departs from it, with a reason and a named person who accepted the departure. That deviation list is where the interesting content of a plan usually lives. ## A worked example Take a 4-person team owning an airline seat-map service. Their whole strategy fits on one page: two automated levels run on every commit, the seat-map service is verified against a stand-in for the reservation dependency rather than the live one, every defect that reaches production gets a permanent automated check, the team owns quality and there is no separate verification group. Their plan for the September seat-map release is a different document: three new fare-class rules in scope, code freeze on the 14th, two of the four engineers on verification for six working days, deliverable is a written recommendation, and the top risk carried is the intermittent timeout seen on roughly 2.7% of seat-map reads during the previous release. The head of delivery signs. None of that belongs in the strategy; all of it matters for six weeks and then stops mattering. ## Where teams go wrong Three failure modes recur. First, **one merged document**: the standing choices are buried inside a release plan, so when the release is archived the organisation loses its only written statement of how it tests. Second, **an inherited template**: a long plan whose section headings came from a standard nobody on the team has read, half of them left empty or filled with prose that decides nothing. Third, **no strategy at all but a strong implicit one**: the team has firm habits about levels and automation that live only in people's heads, which works until the fifth joiner asks where a new kind of check belongs and gets three different answers. ## What an interviewer is listening for A clean one-sentence distinction, then one concrete section from each document, then the observation that the split exists because the two change at different rates. Candidates who can also say what they would *delete* from a plan they inherited are the ones who have actually maintained these documents rather than only been handed them.
- If one delivery needs to depart from the standing strategy, where does that get recorded?In that delivery's test plan, as an explicit deviation: what is being done differently, why, for how long, and who accepted it. Silently ignoring the strategy is the worst option, because the next reader cannot tell a deliberate choice from a lapse. If the same deviation appears in three consecutive plans, that is evidence the strategy itself is wrong and should be amended.
- Who should write and approve each of the two documents?The strategy is written by whoever owns the way of working across the teams it binds - a lead engineer, a quality lead, or the teams jointly - and it needs enough authority behind it that a team cannot quietly ignore it. The plan is written by the people running that delivery, and approved by whoever will accept the outcome. A strategy written by someone who never sees the code tends to be ignored.
- A team keeps no written documents at all. Does it still have a test strategy?It has an implicit one: real decisions about levels, stand-ins, automation and ownership are being made every day, just not recorded. That is workable while the team is small and stable and expensive once it grows or turns over, because the decisions cannot be questioned, inherited or deliberately changed. Writing one page is usually cheaper than the argument it prevents.
The strategy is the club's standing rules of play; the plan is the team sheet for Saturday's match.
saying these in an interview costs you the question
- Uses the two terms as if they meant the same document
- Puts release dates and staffing into the standing strategy
- Rewrites the strategy for every two-week release
- Assumes only a separate test team may write either document
- Judges a plan by its length rather than its decisions
- Repeats the strategy inside every plan instead of citing it