Writing a test strategy
The standing document: what this organisation tests, at which level, with what tooling, and what it deliberately does not test. It changes maybe twice a year and it settles a hundred arguments. Most teams have never written one down, which is precisely why they keep having the same argument.
Two documents get confused constantly, and the difference is easy once you see it.
A shared kitchen has house rules on the wall. Wash up before you leave. Label anything in the fridge. Nobody's food gets thrown out without asking. They were agreed once, they change maybe twice a year, and they settle a hundred small arguments before anyone has them.
Tonight's dinner is a different piece of paper: who is cooking, what we are making, what to buy.
A test strategy is the house rules. A test plan is tonight's dinner. Most people are asked for the second and have never seen the first. That is exactly why the same argument keeps happening.
The six things it has to settle
Write nothing else until these six are answered. Every one of them is an argument you have already had.
- Who tests what. Do developers write unit tests? Does QA touch code? Who owns the pipeline? Say it plainly.
- Which levels we test at. Unit, integration, end-to-end, manual exploratory. Roughly what share of effort goes where, and why. It is the pyramid or trophy question, answered once for your context instead of re-argued per feature.
- What "tested" means before something ships. Not a feeling. A named set of checks that must have passed.
- What we do not test. The single most useful line in the document. Browsers you do not support, load levels you do not simulate, third-party systems you trust.
- Environments and data. Where testing happens, where the data comes from, and the rule about production data. This one keeps you out of trouble, and it is where a defensible test record starts.
- How we decide it is good enough. Who signs off, and against what.
Why you should care about this
Because without it, every release re-negotiates the same questions under time pressure, and the answer depends on who is in the room.
You have lived this. It is Friday afternoon, something is half-tested, and the argument starts. It is not really about this feature. It is about who was supposed to test it, at what level, and what "done" meant.
A strategy does not remove the pressure. It removes the argument, because the answer was written down while everybody was calm.
It also changes how you are treated. Anyone can report bugs. Writing down how the organisation tests, getting it agreed, and being able to point at it is visibly more senior work. It takes an afternoon rather than a promotion.
A strategy is not a description of testing. It is a list of decisions, made while nobody was under pressure, that stop the same argument recurring every release.
How you write one
1. Write the current reality first, not the ideal. Describe what actually happens today, even where it is embarrassing. A document describing a fantasy gets ignored on contact with the first release.
2. Take it from the arguments. Go through the last three releases and list every disagreement about testing. Each one becomes a line. Include the ones about numbers, because which metrics you report belongs in a strategy rather than in a monthly debate. This is why yours will beat any template: templates do not know your arguments.
3. Keep it to two pages. If a section needs more, it is a separate document. Nobody reads a twenty-page strategy, which means nobody follows it.
4. Name owners, not teams. "QA" does not own anything; a person does. Roles are fine, but a role with a name beside it is better.
5. Get it agreed out loud. One meeting, read it through, change what people disagree with. An unagreed strategy is just your opinion in a nicer font.
6. Date it and review it twice a year. Undated documents rot invisibly. A date tells the next reader how much to trust it.
A filled-in example
Here is what one looks like in full, for a small system. Not a template full of square brackets, but an actual strategy you could adapt in an hour.
WILLOW BOOKS — TEST STRATEGY
Owner: Priya N (QA) Agreed: 2026-07-02 Review: 2027-01 Version: 3
WHAT WE ARE
A small online bookshop. Next.js storefront, Node API, Postgres, Stripe for
payments. Six engineers, one tester, a release most Thursdays.
WHO TESTS WHAT
Engineers unit tests for their own code; must pass before review
Engineers one happy-path API test per new endpoint
Priya (QA) exploratory testing of every story, the regression pack,
the release decision
Engineers fix their own failing tests; QA does not fix product code
Nobody yet performance. See out of scope.
LEVELS AND WHERE EFFORT GOES
~60% automated API and unit tests, run on every pull request
~20% automated browser tests, checkout and account journeys only
~20% human exploratory testing, focused on what changed this week
We do not automate a journey until it has run green manually twice.
WHAT "TESTED" MEANS BEFORE A RELEASE
1 pipeline green (unit, API, browser)
2 every story in the release exploratory-tested and its acceptance
criteria checked
3 regression pack run on staging, no open critical or high defects
4 Priya's one-line release note in the ticket
WHAT WE DO NOT TEST (deliberate)
- Performance and load. We are under 400 orders a day. If that changes,
this line changes first.
- Browsers below 1% of traffic (currently IE, Opera Mini, Samsung < 20).
- Stripe's own behaviour. We test our integration, not their platform.
- Email rendering in more than three clients (Gmail, Outlook, Apple Mail).
- Accessibility beyond automated axe checks plus keyboard navigation on
checkout. This is a known gap, not an oversight.
ENVIRONMENTS AND DATA
local engineers, seeded fixtures
staging release testing, restored weekly from anonymised production
production smoke checks only, read-only, no test orders
Rule: no unmasked customer data leaves production. Ever. No exceptions
for "just debugging".
WHO DECIDES IT SHIPS
Priya recommends. Sam (product) decides. Disagreement goes to Dan (CTO).
Nobody ships on a Friday after 15:00.
WHEN WE BREAK THESE RULES
Hotfixes may skip the regression pack. They may not skip the pipeline or
the exploratory check. Every skip gets a line in the release ticket.Read the out-of-scope section again. Five lines, and every one of them is a conversation that now never has to happen twice. That is what a strategy is for.
How to show you know it
A strategy for your own team, dated and agreed. Start from your first project setup if you are writing one from scratch. Two pages. Very few testers at any level have written one, and it is visible senior work.
An out-of-scope list. The part that proves you understand a strategy is decisions, not description.
The arguments it came from. "These six lines each come from a specific disagreement in the last three releases." That sentence is the difference between your document and a downloaded template.
A review date that has actually been honoured. Nothing says professional quite like a document on version 3.
Questions
Is this the same as a test plan?
No, and mixing them is the most common mistake here. The strategy is the house rules, standing and general. The plan is tonight's dinner, specific to one release or project. A plan usually points at the strategy rather than repeating it.
We are five people. Do we need one?
You need it more than a large company does, because you have no process to hide behind. Two pages will do. The example above is a six-engineer team.
Who has to approve it?
Whoever can overrule you on a release decision, which usually means product and engineering leadership. Approval is the whole point, because an unagreed strategy settles nothing.
Can I have AI write it?
It can give you a competent generic skeleton in thirty seconds, and the skeleton is the least valuable part. The six decisions and the out-of-scope list have to come from your team's actual arguments. That split is its own topic later on this layer.