Writing a test plan (and a test strategy)
What a test plan is, the sections that matter (scope, approach, resources, schedule, risks, entry and exit criteria), how it differs from a test strategy, and a compact template you can copy.
Before a road trip, you decide where you're going, who's driving, what you're packing, and when you'll stop for fuel. You could just start the engine and hope, but you'd waste time and probably forget something important. A test plan is that trip plan for testing: it answers what we'll test, how, by whom, by when, and how we'll know we're done, written down before the engine starts.
You won't write a giant formal plan for every tiny task. But for a real feature or release, a clear plan saves everyone from the two classic disasters: testing the wrong things, and arguing at the end about whether you're finished.
The sections that actually matter
| Section | The question it answers |
|---|---|
| Scope: in | What are we testing? (the checkout flow, the new search) |
| Scope: out | What are we explicitly not testing this time? (saying so prevents nasty surprises) |
| Approach | How will we test it: manual, automated, which techniques and test levels? |
| Test environment | On what browsers, devices, data, and accounts will we run? |
| Resources | Who does the work, and what tools do they need? |
| Schedule | When does testing start and finish? What are the milestones? |
| Risks | What could derail us, and what's our backup plan? |
| Entry criteria | What must be true before testing can start? (code merged, build deployed) |
| Exit criteria | What must be true before we can stop and call it done? |
Most testing arguments are really arguments about "are we done?" Decide the exit criteria up front (for example "all critical and high bugs fixed, 95% of planned cases run, zero open blockers") and the answer becomes a checklist instead of a shouting match.
A compact template you can copy
- 1
1. Overview
One paragraph: what's being released, and why this round of testing exists.
- 2
2. Scope (in and out)
Bullet what you will test, then bullet what you won't. The 'won't' list is the one people forget and later regret.
- 3
3. Approach
Manual vs automated, which test levels (unit / integration / system / acceptance), which design techniques, and what kinds of testing (functional, performance, security, accessibility).
- 4
4. Environment and data
Browsers, devices, screen sizes, test accounts, and where the test data comes from.
- 5
5. Roles and schedule
Who owns what, start and end dates, and any milestones along the way.
- 6
6. Risks and mitigations
Each likely risk paired with a plan B. 'The staging server might be unstable, so we keep a local fallback build.'
- 7
7. Entry and exit criteria
The checklist that says when testing may begin and when it is officially complete.
Test plan vs. test strategy
These two get muddled constantly, so here's the clean line. A test strategy is the big-picture, long-lived document for an organisation or a whole product: how this company approaches testing in general: its standards, its preferred tools, its quality philosophy. It changes rarely. A test plan is specific and short-lived: it's for one project, feature, or release, and it follows the strategy's rules while filling in the concrete details.
Test strategy
- Big-picture and organisation-wide.
- Long-lived: changes rarely.
- Sets the standards, tools, and philosophy.
- Answers: how do we test here, in general?
Test plan
- Specific to one project or release.
- Short-lived: written, then retired.
- Fills in concrete scope, schedule, and people.
- Answers: how do we test this thing, this time?
A handy way to remember it: the strategy is the constitution, the plan is the law you pass for one occasion. The plan must obey the strategy, but it's where the real, day-to-day detail lives.
A test plan is a living tool, not a trophy. If scope changes mid-project (it will), update the plan and tell the team. A beautiful plan that no longer matches reality is worse than a scrappy one that does.
- A test plan answers what you'll test, how, by whom, by when, and how you'll know you're done.
- The sections that matter most: scope (in and out), approach, environment, resources, schedule, risks, and entry/exit criteria.
- Define exit criteria up front so 'are we done?' becomes a checklist, not an argument.
- A test strategy is the big-picture, long-lived approach; a test plan is the specific, short-lived document for one release.
- Keep the plan alive: update it when scope changes rather than letting it drift out of date.