Writing a Test Strategy

Someone asks you to 'write the testing document' for a new payment service. You spend four days producing a 20-page artifact with a schedule, named test cases, and daily milestones — and the architect returns it saying she wanted to know the testing approach for the whole platform, not the schedule for one service. You wrote a plan; she wanted a strategy. The two documents differ in audience, lifespan, and altitude, and knowing which is being asked for is the first professional skill of test planning.

A test strategy is organization-level and long-lived. It answers: how does this team or product test, in general? It is written or approved by a test manager or QA lead, reviewed by architecture and product leadership, and changes when the platform, tooling, or risk profile changes — typically annually or after a major architecture shift. A test plan is project- or release-level and short-lived. It answers: how will this release or feature be tested, by whom, when, against what environment, and with what exit criteria? It is written by the QA owner of that release and changes every sprint as scope moves.

Both frameworks formalize this. ISTQB defines a master test plan, level plans, and a strategy that sets policies all plans inherit. IEEE 829 (and its 2008 successor 29119-3) enumerates plan contents; the strategy appears there as the context that constrains them. Cite whichever the interviewer's company uses — but know the distinction is universal.

Why the distinction matters beyond vocabulary: the strategy is what prevents every team from reinventing testing. When three squads each plan a release, the strategy is what makes their plans share environments, tooling, defect severities, and regression policy. Without it, squad A tests with Selenium, squad B with Playwright, nobody owns the shared staging environment, and cross-team defects fall between them. The strategy is also the first document a new QA hire reads to learn 'how we test here' — it encodes decisions that were expensive to make.

A healthy relationship between the two documents is inheritance with local override: the release plan cites strategy policies (defect severities, regression depth, environment list) and only documents deltas (this release's scope, schedule, extra risk). When a plan contradicts the strategy, one of two things must happen: the strategy gets amended deliberately, or the plan is wrong. Plans silently contradicting strategies is how organizations accumulate three different testing cultures under one brand.

Interview framing: 'what is the difference between a test strategy and a test plan?' is a filter question — the expected answer names audience (leadership vs team), lifespan (months vs weeks), and content (approach/policy vs schedule/cases). Answer it crisply, then signal that you have actually written both, which sets up every follow-up.

A strategy nobody reads is worse than none, because it still takes a week to write. The ones that get read are short, decision-dense, and organized so a reader can find the answer to their question in one scan. Eight sections cover it — start from a real service, say an online payment platform.

1. Scope and objectives. What is tested and, crucially, what is not: 'This strategy covers the payment API, checkout web app, and notification workers. Hardware-level failover testing of the card terminals is performed by the vendor under contract.' Explicit exclusions prevent scope drift arguments later.

2. Business and risk context. Why this level of rigor: 'Payments are PCI-DSS scoped; a defect here blocks revenue directly. Historical defect density in the fraud module is 3× the platform average.' This section justifies everything below it and is where risk-based prioritization gets anchored.

3. Test levels and types per feature area. The core mapping:

4. Test process and lifecycle. The flow everyone follows: when test design starts (refinement), execution cadence (per-merge, nightly, pre-release), defect workflow states, and regression policy (what re-runs and when).

5. Environments and test data. A named list with purpose: dev, staging (schema-mirrored, third-party sandboxes), pre-prod (prod-scale data shape, masked), plus the test data approach — seeded factories, anonymized production copies, and rules for handling card numbers even in test (never real PANs, even encrypted).

6. Tooling. Playwright for web E2E, pytest for API, Pact for contracts, k6 for load, Allure for reports, Jira for defects — each tool named with its purpose, because 'we use Selenium' is not a tooling decision unless the strategy says what it is used for and what it is deliberately not used for (unit-level coverage stays in the code repos).

7. Roles and responsibilities. Who writes unit tests (developers, gate on merge), who owns API and E2E suites (QA), who signs acceptance (product owner), who approves severity escalations (QA lead with product), and who maintains the shared environments.

8. Entry/exit standards, metrics, and review triggers. Cite the organization's exit-criteria template (coverage, defect thresholds, sign-off), the metrics that will be reported (escape rate, flaky rate, coverage), and the triggers that force a strategy review: 'new architecture stream, regulatory change, timeline compressed by >25%, or any two consecutive releases with escape rate above 5%.'

Two properties make the document survive contact with reality. First, decisions, not adjectives: 'E2E scope is the 20 journeys that touch money' beats 'adequate end-to-end coverage'. Second, one home: store the strategy in the repo's docs folder or the team wiki with an owner and a last-reviewed date — a strategy attached to an email from 2023 is a lost document. Review triggers are the mechanical answer to the 'it went stale' problem: the document does not need discipline, it needs alarms.

You finish the strategy draft and circulate it. The responses reveal the real job: the developers object to the environment section (they own the CI runners and will not double them), product objects to the scope exclusions ('but what if the notifications are wrong?'), and nobody has read past page two. A strategy is a negotiated contract about quality, and adoption is a stakeholder-management skill as much as a testing skill.

Run the review as a working session, not a document hand-off. Walk each decision that costs someone something: the environments section costs infra time, the levels table costs developer effort for unit-test coverage, the exclusions cost product's appetite for risk. Give each stakeholder the specific paragraph that affects them and ask for objections in writing. In the session, expect and prepare for the three classic objections:

• 'This is heavier than we need.' Answer with risk data, not rigor: payment flows and fraud rules get the deep treatment because defects block revenue; the marketing pages get smoke coverage. Offer to cut whole rows of the levels table if their risk assessment differs — that negotiation is the strategy working.
• 'We cannot afford these environments.' Propose the cheaper ladder: schema-mirrored staging with third-party sandboxes for 95% of testing, pre-prod used only for load and failover. Quantify: one staging env at $400/month versus the loaded cost of a payment incident.
• 'Developers should own all the testing.' Agree on the split instead of the slogan: developers own unit and component levels (Q2 in the quadrants), QA owns system and acceptance plus exploratory critique; cross-check the arrangement against escape-level data after two releases.

After sign-off, the strategy earns its keep through three maintenance habits. Cite it from plans: every release test plan links to the strategy sections it inherits, so divergence is visible. Review on trigger: the alarms you defined (architecture change, timeline compression, escape-rate breach) actually convene a 30-minute review. Publish its metrics: when the quarterly quality report opens with 'per our strategy, escape rate is 4.2% against a 5% threshold', the document is alive; when nobody can quote it, it is shelf-ware.

In interviews, the question 'have you written a test strategy? what did it contain?' separates experience levels. A junior answer recites section names. A strong answer describes one real decision from each costly area — a scope exclusion you had to defend, an environment compromise, the unit/system ownership split — and ends with how you knew the strategy was being followed (plans citing it, review triggers firing). That structure signals you have been through the negotiation, not just the writing.

One more adoption tactic survives from the best-run teams: the strategy has a visible owner and a quarterly ten-minute read-through at the quality sync. Ownership is not custody — it means that when someone proposes a new tool or drops a test level, the owner checks the proposal against the strategy and either amends it deliberately or asks the team to revisit the decision in the open. Strategies die quietly when no one is accountable for their consistency, and they die loudly when they are enforced without an amendment path. The visible owner plus the written review triggers is the combination that keeps the document both alive and legitimate — the same living-document discipline you will apply to the release test plan next.

Once the strategy's policies are set, the per-release work of applying them — features, cases, owners, schedule, and measurable exit criteria — is Building a Test Plan.