Writing a test plan

Somebody has asked you for a test plan and you have until Friday.

Here is the reframe that makes it easy. A test plan is not a policy document. It is the plan for one journey.

You are driving somewhere on Saturday. Where are we going. Who is coming. What are we taking. What could go wrong. When do we leave and when do we need to arrive. That is a test plan, and nobody needs fifteen pages to describe a car journey.

The reason people dread it is that they have only ever seen the enterprise version: forty pages, twelve of them boilerplate, written to satisfy a process rather than a reader.

The eight sections

In the order they belong on the page. For example, on the gift-card release below, scope took four lines and out-of-scope took six.

1. What this is for. Two sentences. Which release, which feature, why we are testing it.
2. Scope. What is being tested. Be specific: features, journeys, platforms.
3. Out of scope. What is not, and why. The most-quoted section in any plan.
4. Approach. How you will test it: automated where, manual where, exploratory charters, and what data you need. Scoring what to automate first is the method behind that split.
5. Environments and data. Where, with what, and who sets it up.
6. Risks. What could go wrong with the testing, plus what worries you about the product. Each with a response.
7. Schedule and dependencies. When testing starts, what has to be ready first, when you will report.
8. Entry and exit criteria. The conditions to start and the conditions to stop, agreed now rather than argued about later.

Why you should care about this

Because the plan is where you get to set expectations while you still have leverage.

Every uncomfortable end-of-release conversation is a scope, dependency or criteria conversation that nobody had at the start. "I did not know that was in this release." "The test data was never ready." "You said it was tested." A plan is your one chance to answer all three in writing before anyone is under pressure.

It is also the most-searched document in testing, and it is answered terribly. The pages you find are blank templates with square brackets, which is why writing one still feels hard even after reading three of them. So the useful part of this topic is not the section list. It is the filled-in example below.

How you write one in an afternoon

1. Get the scope from the tickets, not from a conversation. List the actual stories in the release. Read each one. If something is ambiguous, that is your first risk.

2. Write out-of-scope while the scope is fresh. Anything adjacent that people might assume is included: other platforms, migrations, the third-party thing, last release's known bugs.

3. Ask what could stop you testing. Test data, an environment, a dependency, a colleague on holiday, a feature flag nobody controls. These are your testing risks and they are more predictable than product risks.

4. Name the product risks with the team. Ten minutes in refinement. "What in this release worries you?" Engineers answer this well and honestly, and their answers reshape where you spend your effort.

5. Set exit criteria you would genuinely hold. Charters come from session-based testing, which is where the 90-minute timebox in the example comes from. If you would ship with two open medium bugs, do not write zero open bugs. A criterion you would waive is worse than none, because it teaches everyone that criteria are decorative.

6. Circulate it and get one round of comments. Product, tech lead, whoever signs off. Fifteen minutes of their attention now saves a week of argument later.

7. Keep it open during the release and mark it up. Annotations belong with the release record, not in a private file. A plan that is never touched after day one was a formality. Annotate what changed, and that becomes your test summary report at the end with almost no extra work.

A complete filled-in plan

Same small system as the strategy. This is the whole document, nothing elided.

Look at the risks section. Five risks, each with a named owner and a response. One is simply documented rather than solved, and one is about the tester's own holiday. That honesty is what makes a plan useful rather than decorative.

How to show you know it

A two-page plan for a real release. With the four sections that matter filled in properly. This is the artefact people ask for in interviews and almost nobody has a good example of.

A risk that you documented rather than solved. R4 above. It shows you know a plan records reality instead of pretending everything is covered.

Exit criteria you actually held. Or, better, a story about the release where you held them and what happened. That is the difference between writing criteria and meaning them.

A plan you marked up during the release. Annotations showing what changed, which becomes your summary report for free.