Test plan template: a lean plan your team will keep up to date

A test plan template gives your team one short list of questions to answer before testing starts: what you will test and what you will not, which user flows matter most, where each kind of test runs, which data and accounts the tests need, when a build is ready to test and when it is ready to ship, who does what, and what is still unknown. For a small team the answers fit on one or two pages, and the plan is only worth writing if it stays true as the product changes.

This guide covers what goes in a formal software test plan, a lean version in nine sections for an agile team, a Markdown template to copy into your repository, and a filled example for a fictional web application.

What goes in a formal test plan

Two standards have shaped test documentation. IEEE 829 dates from 1983: the summary of that first edition describes a set of basic test documents and defines the purpose, outline and content of each. It was revised in 1998 and 2008, and the summary of the 2008 edition ties the breadth and depth of test documentation to the integrity level of the software. IEEE now lists IEEE 829 as superseded by the first four parts of ISO/IEC/IEEE 29119.

Part 3 of ISO/IEC/IEEE 29119, Test documentation, is the current reference. Its 2021 edition, which replaced the 2013 one, was published by IEEE on October 28, 2021, and the IEEE Standards Association lists it as active as of October 2026. Its official summary says it contains templates and examples of test documentation, arranged by the test process that produces each document, that it supports manual and automated, scripted and unscripted testing, and that the templates can be used with any software development lifecycle model.

We have not read the full text of either standard. Both are sold (the IEEE pages offer them for purchase or by subscription), so the two paragraphs above say only what the official IEEE pages state. For what goes inside a test plan, we used the ISTQB Certified Tester Foundation Level syllabus, version 4.0.1, the edition on the ISTQB site as of October 2026. It lists the typical content of a test plan and refers readers to Part 3 of ISO/IEC/IEEE 29119 for the details:

• Context of testing: test scope, test objectives, test basis
• Assumptions and constraints of the test project
• Stakeholders: roles, responsibilities, relevance to testing, hiring and training needs
• Communication: forms and frequency of communication, documentation templates
• Risk register: product risks and project risks
• Test approach: test levels, test types, test techniques, deliverables, entry and exit criteria, independence of testing, metrics, test data and test environment requirements, and deviations from the test policy and test strategy
• Budget and schedule

The syllabus puts much of the value in the thinking, not the document: preparing a test plan “is a useful way to think through the efforts needed to achieve the test objectives”. The full outline suits a project with a test manager and stakeholders who expect a formal document. A team of five that ships every week needs the same thinking in far less space.

A lean test plan template for agile teams

The lean version keeps every question that changes a decision and drops the rest. Its nine sections map onto the typical content like this:

Typical content	In the lean plan
Context of testing	Scope and out of scope
Risk register: product risks	User flows ranked by risk
Test environment requirements	Platforms and environments
Test levels and test types	Test levels and where each runs
Test data requirements	Test data and accounts
Entry and exit criteria	Entry and exit criteria
Stakeholders	Roles
Project risks, assumptions	Risks and open questions
Budget and schedule	Schedule
Communication, techniques, metrics	Left out until someone needs them

Scope and out of scope

Name what the plan covers: the web app, the public API, the next release or the next quarter. Then list what you will not test, with the reason: a mobile app that is not built yet, load testing, the internals of your payment provider. A written out of scope list stops anyone from assuming that everything was checked.

User flows ranked by risk

List user flows, not features or code modules. A flow is one journey from start to finish, such as sign-up or paying an invoice. Score each flow from 1 to 3 for how likely it is to break and for how much it would hurt, multiply the two, and let the score set the depth: end-to-end tests on every pull request for the highest scores, a smoke check before each release for the middle, exploratory testing or a written risk for the rest. Our guide to risk-based testing walks through the scoring. In the plan, keep a single table of flow, score and tier. It is the section you will update most.

Platforms and environments

List the browsers, devices and operating systems you support, and which of them the automated tests cover. In Playwright Test you run the same tests in several browsers by defining one project per browser in the config, and the Playwright docs show projects for Chromium, Firefox and WebKit as well as branded Chrome and Edge, so the plan and the config can name the same list. Then name the environments (a preview build per pull request, staging, production) and what is faked in each: payments in test mode, email to a test inbox.

Test levels and where each runs

For each kind of test, say what it checks, where it runs and who owns it. The split we start from for a small web team:

Level	Runs	Checks
Unit	Every push	Logic inside one module
API	Every pull request	Endpoints and multistep journeys
End-to-end	Every pull request	The flows that scored 6 or 9
Exploratory	Before each release	New features, by a person

This is the shape the ISTQB syllabus describes as the test pyramid: tests at the bottom are small, isolated and fast, so usually you need many of them, while end-to-end tests at the top are slower and check large pieces of functionality, so usually just a few are needed. For exploratory testing the syllabus describes sessions: a defined time box, a charter with test objectives, and a debrief afterwards. List the charters for the next release in the plan.

Test data and accounts

Write down where test data comes from and which account each test uses. Three rules keep it manageable: every test creates the data it needs (a fresh workspace, a unique email), so tests can run in parallel and in any order; every role gets its own test account, with the credentials in your CI secrets; and no real customer data goes into a test environment. If tests sign in once and reuse the session, the Playwright authentication guide recommends saving that state in a playwright/.auth folder and adding it to .gitignore, because the file could be used to impersonate your test account.

Entry and exit criteria

Entry criteria say when a build is ready to test, exit criteria say when testing is done. The ISTQB syllabus notes that in agile teams exit criteria are often called the Definition of Done, and the entry criteria a user story must meet before work starts are called the Definition of Ready. Make each criterion a yes or no question: “every test tagged @pr passed on this build” can be checked, “good coverage” cannot. The syllabus also accepts running out of time as a reason to stop, if the stakeholders have reviewed and accepted the risk of going live without further testing, so write down who may accept it. The exit criteria then feed the release decision, and our Go/No-Go release checklist turns them into a template for the release ticket.

Roles

Name people, not teams: who signs the release call, who keeps the plan and triages failures, who writes which tests, who scores impact. One person can hold several roles. The point is that nobody has to ask.

Risks and open questions

Keep a short table of what could derail testing and what nobody has answered yet: a payment sandbox that is often slow, a browser version nobody has decided to support, a tax rule still under discussion. Each line gets an owner and a date. Add the flows you decided not to test, so the person who signs the release knows what is not covered.

Schedule

For a team that ships continuously the schedule is a rhythm, not a Gantt chart: when the release branch is cut, when exploratory sessions happen, when the Go/No-Go review is, and when the plan itself gets reviewed.

The test plan template to copy

Save it as docs/test-plan.md in your repository, next to the tests. Replace everything in angle brackets.

# Test plan: <product or release>

Owner: <name>
Last reviewed: <date> | Next review: <date>
Links: <CI pipeline>, <bug tracker>, <Go/No-Go template>

## 1. Scope

In scope:

- <apps, platforms, APIs and releases this plan covers>

Out of scope, and why:

- <what is not tested>: <reason>

## 2. User flows ranked by risk

Likelihood (L) and impact (I) from 1 to 3, score = L x I.
Tiers: 6 or 9 = end-to-end on every PR (@pr). 3 or 4 = smoke check before
release (@smoke). 2 = exploratory when it changes. 1 = not tested, see 8.

| Flow   | L x I           | Tier   |
| ------ | --------------- | ------ |
| <flow> | <L x I = score> | <tier> |

## 3. Platforms and environments

- Supported browsers and devices: <list>
- Covered by automated tests: <which ones, and when>
- Environments: <preview per PR, staging, production>
- Third parties and how they are faked: <payments, email, sign-in>

## 4. Test levels and where they run

- Unit: <when, where, owner>
- API: <when, where, owner>
- End-to-end: <tier, when, browsers, command>
- Exploratory: <when, how long, who>
  Charters for the next release: <list>
- Smoke after deploy: <what, where>

## 5. Test data and accounts

- Test data: <how each test gets its data, reset schedule>
- Accounts: <one per role, where the credentials live>
- Never in test data: <real customer data, real cards>

## 6. Entry and exit criteria

Ready to test:

- [ ] <build deployed, health check green>
- [ ] <acceptance criteria written for every story>

Ready to ship:

- [ ] <tests that must pass on this build>
- [ ] <every failure triaged>
- [ ] <no open bug of severity ...>
- [ ] <untested flows and open risks listed in the Go/No-Go report>
- [ ] <who may accept the remaining risk if time runs out>

## 7. Roles

- Release owner (signs the Go/No-Go call): <name>
- QA owner (keeps this plan, triages failures): <name>
- Developers: <what they test>
- Product: <scores impact, writes acceptance criteria, explores>

## 8. Risks and open questions

| Item                              | Owner  | Due or status    |
| --------------------------------- | ------ | ---------------- |
| <risk, question or untested flow> | <name> | <date or status> |

## 9. Schedule

- Release rhythm: <when releases happen>
- Testing window: <when the full run and exploratory sessions happen>
- Plan review: <when this file is reviewed>
- Milestones: <launches, deadlines>

A test plan example for a web application

Here is the template filled in for a fictional product: an invoicing web app for freelancers, with a public API and card payments through a payment provider. The team has five people, no QA department and a release every Tuesday. The product, the people and the dates are made up.

# Test plan: invoicing web app (fictional example)

Owner: Dana (lead developer, QA owner)
Last reviewed: 2026-10-12 | Next review: 2026-11-09
Links: CI pipeline, bug tracker, Go/No-Go template

## 1. Scope

In scope:

- The web app on desktop browsers and the public REST API (v1)
- Weekly releases from October to December 2026

Out of scope, and why:

- iOS app: not built yet, planned for 2027
- Load and security testing: a separate review before the EU launch
- The payment provider itself: we test our side of the integration only

## 2. User flows ranked by risk

| Flow                                  | L x I     | Tier                      |
| ------------------------------------- | --------- | ------------------------- |
| Create and send an invoice            | 3 x 3 = 9 | @pr                       |
| Client pays an invoice by card        | 3 x 3 = 9 | @pr                       |
| Sign up and send the first invoice    | 2 x 3 = 6 | @pr                       |
| Sign in and reset a password          | 2 x 3 = 6 | @pr                       |
| Recurring invoices go out on schedule | 2 x 3 = 6 | @pr (API test)            |
| Invite a teammate                     | 2 x 2 = 4 | @smoke                    |
| Export invoices to CSV                | 1 x 3 = 3 | @smoke                    |
| Invoice branding (logo, colors)       | 2 x 1 = 2 | Exploratory when changed  |
| Dark mode                             | 1 x 1 = 1 | Not tested, see section 8 |

## 3. Platforms and environments

- Supported: latest two versions of Chrome, Edge, Firefox and Safari, desktop
- Automated: Chromium on every PR; Chromium, Firefox and WebKit before release
- Phone browsers: Safari on iPhone, by hand in exploratory sessions
- Environments: preview build per PR, staging (reset nightly), production
- Payments in test mode and email to a test inbox on preview and staging;
  the production smoke check never pays

## 4. Test levels and where they run

- Unit: every push, in CI, developers
- API: every PR, against the preview build, developers
- End-to-end, @pr: every PR, Chromium, QA owner
  npx playwright test --grep @pr --project=chromium
- End-to-end, full: before each release, on staging, all three browsers
  npx playwright test --grep "@pr|@smoke"
- Exploratory: Monday before each release, 60-minute sessions,
  product lead and QA owner
  Charters for the release of 2026-10-20:
  - New discount codes: totals, rounding and tax with odd amounts
  - Paying an invoice on a slow phone connection
- Smoke after deploy: production, sign in and open an invoice

## 5. Test data and accounts

- Each test creates its own workspace through the API, with a unique name,
  so tests run in parallel and in any order
- Accounts: owner, member and accountant (view only) in each environment;
  credentials in CI secrets
- Signed-in state saved to playwright/.auth, which is in .gitignore
- Never in test data: customer data, real cards (provider test cards only)

## 6. Entry and exit criteria

Ready to test:

- [ ] Release build deployed to staging, health check green
- [ ] Every story in the release has acceptance criteria
- [ ] Seed data loaded, all three test accounts can sign in

Ready to ship:

- [ ] Every @pr and @smoke test passed on this build, none skipped
- [ ] Every failure triaged: product bug, test problem or environment
- [ ] No open bug of severity 1 or 2 in this release
- [ ] Exploratory notes linked in the release ticket
- [ ] Untested flows and open risks listed in the Go/No-Go report
- [ ] Out of time: only the CTO can accept the remaining risk, in writing

## 7. Roles

- Release owner (signs the Go/No-Go call): CTO
- QA owner (keeps this plan, triages failures): Dana
- Developers: unit and API tests for their own changes, bug fixes
- Product lead: scores impact, writes acceptance criteria, explores
  new features
- Support: reports user problems with steps and screenshots

## 8. Risks and open questions

| Item                                              | Owner        | Due or status |
| ------------------------------------------------- | ------------ | ------------- |
| Payment webhooks can arrive twice: API test added | Dana         | Done          |
| Scheduler runs only on staging, not on previews   | CTO          | 2026-10-30    |
| Support Safari 16, or only the latest two?        | Product lead | 2026-10-23    |
| Tax rules for the EU launch are not final         | CEO          | 2026-11-13    |
| Not tested: dark mode (score 1)                   | Product lead | Accepted      |

## 9. Schedule

- Release every Tuesday at 11:00; release branch cut Monday at 12:00
- Exploratory sessions Monday afternoon; Go/No-Go review Tuesday at 10:00
- Plan review: second Monday of each month, 15 minutes
- EU launch: 2026-12-01, after the load and security review

Three things to notice. The tier column turns into Playwright tags: tests for the flows that scored 6 or 9 carry @pr, the smoke checks carry @smoke, and --grep selects them at run time (Playwright docs). Every exit criterion is a yes or no question about the release build. And every open question has an owner and a date, so it gets answered instead of carried from one release to the next.

How to keep the plan up to date

• Keep it next to the code. A Markdown file in the repository changes through pull requests, and the history shows why a flow moved.
• Update it in the pull request that changes a flow. A line in your pull request template (“Test plan updated, or not needed”) makes the question routine.
• Review it at the start of each release cycle. A 15-minute review: rescore the flows that changed, close answered questions, move the dates.
• Rescore after an incident. A bug that reached users is new evidence about likelihood, impact or both.
• Cut what nobody reads. A section that never changes a decision is a section nobody will update.

How we write the plan in week 1

Every engagement starts with a plan like this one. In week 1 we set up access, list your user flows with you, rank them by risk, agree the success criteria in writing and get the first tests running in your CI. Claude agents draft the plan from your specs, tickets and code, and a human QA engineer sets the priorities with you and reviews every change to the tests before it is merged. The plan lives in your repository next to the tests, so you keep it if you stop. Before each release you get a Go/No-Go report signed by the QA engineer: what was tested, what failed and what risk is left. Shipping stays your decision. The how it works page shows the first weeks in order, and the qa-plan workflow in our open-source sample project drafts this kind of plan for a single change: scope, a risk table, coverage, environments and data, and measurable exit criteria.

Sources

• IEEE 829 (2008 edition): Standard for Software and System Test Documentation, IEEE Standards Association
• ISO/IEC/IEEE 29119 Part 3 (2021 edition): Test documentation, IEEE Standards Association
• Certified Tester Foundation Level Syllabus v4.0.1 (PDF), ISTQB
• Projects, Playwright documentation
• Authentication, Playwright documentation
• Annotations: tag tests, Playwright documentation

Researched and drafted with Claude, Anthropic's AI model, and checked against the sources it links. Spotted an error? Tell us and we will correct it.