How to write a test plan (with a one-page example)

So far you have learned how to write test cases and how to choose them with test design techniques. But before anyone runs a single test, the team needs to agree on a bigger picture: what are we testing this time, how, who does it, by when, and how do we know we're done?

That agreement is the test plan. In the testing life cycle it is Phase 2, and everything after it follows from it.

What is a test plan?

A test plan is a document that describes the scope, approach, resources and schedule of the testing for a release or project.

It answers six questions:

1. Why are we testing? (the objective)
2. What will we test, and what won't we? (scope)
3. How will we test it? (approach)
4. Where will the tests run? (environment)
5. Who does what, and when? (people and schedule)
6. When do we start, and when are we done? (entry and exit criteria)

A good test plan is written for people, not for a filing cabinet. Developers, product managers and testers should all be able to read it in a few minutes and agree.

Test plan vs test strategy

• A test strategy is the long-term, organisation-wide approach: "We automate all regression tests, every release gets a security scan, and we test on the three most-used browsers." It rarely changes.
• A test plan applies that strategy to one release or project: "For release 2.4 we test discount codes on web and Android from 3 to 7 November."

Small teams often have no separate strategy document; its key rules simply live inside each plan.

The sections of a test plan

Formal templates exist. The IEEE 829 standard was the classic one, and it was later replaced by ISO/IEC/IEEE 29119-3. But most teams use a lighter version of the same ideas:

Section	What it says	Example
Objective	What this testing must prove	Customers can apply valid discount codes and are refused invalid ones
Scope: in	Features and platforms you will test	Discount codes on web and Android; cart, checkout, order history
Scope: out	What you deliberately won't test, and why	iPhone app (next release); restaurant dashboard (unchanged)
Approach	Test levels, types, and manual vs automated	Functional, API and regression tests; regression automated
Environment	Where tests run, with what data	Staging server, test codes, 3 test accounts, payment sandbox
Entry criteria	When testing can start	Build deployed to staging; smoke test passed
Exit criteria	When testing is done	All high-priority tests passed; no open critical bugs
Suspension criteria	When to pause testing	Pause if sign-in is broken, because most tests depend on it
People	Who does what	One test lead, two testers; a developer on call for blockers
Schedule	Key dates	Testing 3–7 November; summary report 8 November
Deliverables	What testing produces	Test cases, run results, bug reports, a summary report
Risks	What could go wrong, and the backup plan	Payment sandbox may be slow: book it early, keep a mock ready

"Out of scope" is the most underrated line in any test plan. Writing down what you won't test avoids the worst surprise of all: a bug in an area everyone thought someone else had checked.

A one-page example

For most releases, the whole plan fits on one page:

If your plan doesn't fit on one or two pages, ask whether every section is really helping someone make a decision.

Risk-based testing: deciding what matters most

There is never time to test everything equally. Risk-based testing spends the most effort where a failure is both likely and harmful:

For each feature, ask two questions:

• How likely is it to break? New code, complex code, code that changed a lot, or code with a history of bugs.
• How bad is it if it breaks? Money, personal data, sign-in and anything that stops customers ordering.

Put the answers in the plan. They decide the order of testing and where the deepest test cases go, and they tell everyone what was tested lightly if time runs out.

How to write one, step by step

1. Read the requirements, and ask questions (STLC Phase 1).
2. Write the objective in one sentence.
3. List what's in and out of scope, with a reason for each "out".
4. Rank the risks, using the matrix above.
5. Choose the approach: which levels and types, and what to automate.
6. Define entry and exit criteria that can be checked, not "when it looks good".
7. Add people, environment and schedule.
8. Review it with developers and the product owner. A plan nobody agreed to isn't a plan.

Test plans in agile teams

Agile teams rarely write long plans for every sprint. They usually keep:

• A light test strategy for the product, updated a few times a year.
• Testing notes in each sprint: acceptance criteria on every user story, and a short checklist of what is risky this sprint.
• A short release plan for bigger releases: scope, risks and exit criteria.

The questions stay the same. Only the paperwork shrinks.

Common mistakes

• Copying last release's plan without changing the scope or risks.
• Vague exit criteria like "testing is complete". Use measurable ones.
• No "out of scope" section, so gaps stay invisible.
• Writing it alone. Developers know where the code is fragile; product owners know what matters most to customers.
• Never updating it. When the scope changes mid-release, the plan should too.

What's next

In Part 9 we look at what happens when a test fails: how to write a good bug report that developers can act on quickly.

In ProvaLab Test Management, a test plan has these fields built in: objective, test lead, dates, entry and exit criteria, and the features in scope. Test cases attach to the plan, and every test run reports back into it. See it in the two-minute product tour.