How to write a test plan, with a worked example

A test plan is the document that says what will be tested, how, by whom, in what environment, and what has to be true before anyone can call testing finished. It is not a list of test cases. The cases say what you will check; the plan says what you are trying to establish and when you are allowed to stop.

Most test plans are bad in the same way. They are long, they restate the requirement back to the reader, and they contain no sentence that could ever turn out to be false. This article covers the sections that earn their place, with a full worked example at the end for a feature you will recognise.

What a test plan is for

A plan does three jobs, and a section that serves none of them can be deleted.

It settles scope in advance, so that “we didn’t test that” is a decision someone made rather than something discovered afterwards. It states the conditions for finishing, so that the end of testing is a checkable claim rather than the end of the calendar. And it makes the risks visible early enough to do something about them, which is usually the only part anyone thanks you for.

The distinction with a test strategy causes a lot of arguments and matters less than people think. A strategy is organisation-wide and durable: how this company tests, which tools, what the standards are. A plan is for one release, project or feature, and it expires. If you have one document doing both jobs, that is fine for a team of ten, and it stops being fine the moment a second team has to read it.

The sections that earn their place

The international standard for this is ISO/IEC/IEEE 29119-3, which superseded the older IEEE 829. You do not need to buy the standard to write a good plan, and you should not reproduce its full section list in a two-week sprint. The following eight are the ones that carry weight.

Scope, in two halves. What is in, and what is explicitly out. The second half is the one that gets skipped and the one that prevents the argument. “Payment flows on iOS and Android, current and previous OS version” is the first half. “Tablet layouts, the legacy checkout at /v1/checkout, and any currency other than EUR and GBP” is the second. Out-of-scope items are not failures of ambition, they are a record of a decision.

Test items and their versions. Which build, which services, which API version. This sounds like bookkeeping until the day results disagree and nobody can say which commit produced them.

Approach. The levels and types you will run, and the reasoning. Not “we will perform functional, integration and regression testing”, which is true of everything, but which parts get automated, which get exploratory time, and what you are deliberately not doing. If the plan says risk-based, say what makes something high risk here: transaction handling, anything touching stored card data, anything a user cannot undo.

Entry criteria. What has to be true before testing starts. A build deployed to the right environment, the version confirmed, a smoke check passing, test data loaded, access granted. Written down, this converts “we lost Tuesday to the environment” into a condition that was not met.

Exit criteria, as numbers. The part of the document that does the most work, and usually the weakest. “All tests passed” is not achievable and everyone knows it, which is why nobody treats it as binding. Something like this is binding:

All priority-1 cases executed, 100% passed. All priority-2 cases executed, at least 95% passed. Zero open critical or high defects. No more than three open medium defects, each with a documented workaround agreed by the product owner. Regression suite green on the release candidate build. Defect find rate in the final two days below five new defects per day.

That last one is worth stealing. A team still finding defects quickly on the last day is not finished, whatever the pass rate says, and the plan is the only place you can agree that in advance rather than argue about it under pressure.

Environment. What it is, how it differs from production, and who owns it. Name the differences: smaller data volume, mocked payment provider, no CDN. Each difference is a class of defect this cycle cannot find, and writing them down is how those classes get covered somewhere else instead of nowhere.

Risks and mitigations. Real ones, with owners and dates. “Resources may be unavailable” is filler. “The payment provider sandbox has been unstable twice this quarter; if it is down for more than half a day we test against recorded responses and flag the gap in the closure report” is a plan.

Deliverables and schedule. What testing will hand back and roughly when. Cases, execution results per build, defect reports, closure report.

A worked example

Here is a plan for a feature small enough to fit on a page, written the way it would actually be written. The feature: adding saved payment cards to an existing e-commerce checkout, one sprint, web only.

Test plan: saved cards at checkout
Release: 4.12 · Build under test: web-4.12.0-rc3 · Author: QA lead · Date: 2026-09-13

Scope. In: adding a card during checkout, selecting a saved card, deleting a saved card, the card list in account settings, and the behaviour when a saved card is expired or declined. Chrome, Safari, Firefox on desktop, Safari on iOS 17 and 18, Chrome on Android 14 and 15.

Out: adding a card outside the checkout flow (not built yet), Apple Pay and Google Pay (unchanged this release), any currency other than EUR and GBP, and the admin-side refund path. PCI compliance of the provider is out of scope and is covered by the provider’s own attestation; we test that card data never reaches our own servers, not that the provider handles it correctly.

Test items. Web app web-4.12.0-rc3. Checkout service 2.8.1. Payment provider sandbox, API version 2026-04-10. Existing account service, unchanged.

Approach. Risk-based. Highest risk is anything where a user could be charged incorrectly or where card data could be stored on our infrastructure, so those get exploratory time on top of scripted cases. The happy paths and the card list are automated in the existing Playwright suite. Expiry and decline handling are tested against the provider’s documented test card numbers. Cross-browser runs are automated; the two mobile browsers are checked manually on real devices because the payment sheet behaves differently in a simulator.

Deliberately not doing: load testing, because saved cards add one indexed read per checkout and the change is not expected to move throughput; this assumption is recorded as a risk.

Entry criteria. rc3 deployed to staging with the commit hash confirmed against the release ticket. Provider sandbox reachable and returning its version endpoint. Seeded accounts loaded: one with no saved cards, one with three, one with an expired card. All testers have staging access and sandbox credentials.

Exit criteria. All 24 priority-1 cases executed and passed. Priority-2 cases at least 95% passed. Zero open critical or high defects. No more than two open medium defects, each with a workaround agreed by the product owner. Full regression suite green on the final build. No card number, CVV or full PAN present in application logs, database, or any request to our own domain, verified by inspection.

Environment. Staging, one application instance against a 5,000-order database. Production runs six instances against roughly 2.4 million orders. The provider is the sandbox, not live. Consequence: we cannot find performance regressions or genuine provider-side failures here, so the first production release goes out behind a flag to 5% of traffic with the error rate watched for 24 hours.

Risks.

Deliverables. Test cases in the suite, execution results per build, defect reports, a one-page closure report with defect density and the coverage gaps above.

That is the whole document. It fits on one page, every line could turn out to be false, and the exit criteria would let someone who was not in the room decide whether testing is finished.

Test plan template

The example above follows the same eight sections every time, which is what makes a template useful rather than decorative. A good template does two things: it stops you forgetting the section you always forget, which for most people is out-of-scope, and it makes plans from different projects comparable.

Two warnings from reviewing a lot of these. A template with thirty sections gets filled in as thirty headings with one sentence each, which is worse than eight sections done properly, so delete what you do not use. And a template’s default text is the enemy: if the exit criteria field arrives pre-filled with “all tests passed”, that is what will ship, in every plan, forever.

Copy the outline below into whatever your team already writes in: a wiki page, a shared document, or the description of the release ticket. Each line says what the section has to answer, which is the part a blank template usually leaves out.

Test plan: <feature or release>
Release: <version>   Build under test: <build id and commit>
Author: <name>       Date: <date>

1. Scope
   In:  <features, platforms, browsers and versions covered>
   Out: <what is deliberately not tested this cycle, and why>

2. Test items
   <builds, services and API versions under test>

3. Approach
   <what is automated, what gets exploratory time, what makes
    something high risk on this product, and what you are
    deliberately not doing>

4. Entry criteria
   <build deployed and its version confirmed, smoke check passing,
    test data loaded, access granted>

5. Exit criteria, as numbers
   Priority-1 cases executed and passed: <100%>
   Priority-2 cases passed: <at least __%>
   Open critical or high defects: <0>
   Open medium defects: <no more than __, each with an agreed workaround>
   Regression suite: <green on the release candidate build>

6. Environment
   <where testing runs, how it differs from production, who owns it,
    and which classes of defect those differences stop you finding>

7. Risks
   Risk | Impact | Mitigation | Owner

8. Deliverables and schedule
   <test cases, results per build, defect reports, closure report,
    and when each one is due>

The worked example above is this outline filled in for one feature, so it is worth reading the two side by side the first time you use it.

The mistakes worth naming

The most common failure by a distance is exit criteria nobody can check. If yours contain the words acceptable, sufficient, adequate or reasonable, they are not criteria, and under deadline pressure they will not hold anyone to anything.

Close behind is writing the document for nobody. If you cannot name the person who will read it and the decision it will help them make, you are producing an artefact for a process. The readers are usually two: the product owner deciding whether to ship, and the tester who joins in month four and needs to know what was already agreed.

Then there is the plan that stops being true. Scope changes in week two and the document still describes week one. This is worse than having no plan, because a stale plan gets cited. Amend it, or record in the closure report that it was superseded and when.

Last, and easiest to fix: a plan that has swallowed the test cases. The plan should not list individual checks. If it runs past a few pages, most of what is in it belongs in the cases or the strategy.

Where this sits in the wider process

Test planning is the second phase of the software testing life cycle, after requirements analysis and before cases get written. The plan’s exit criteria are what the closure phase is later measured against, so the two are worth writing with each other in mind.

If you want a plan written for your release rather than a template to fill in, that is part of what BetterQA does on test planning engagements, usually starting with the risks the team already suspects and has not written down.

Built by BetterQA