How to Write a Test Plan (With Template and Example)

Two days before a release, someone asks whether anyone tested checkout on Safari, and nobody knows. A test plan is the document that settles that in advance, by saying what you'll test for a release or project, how you'll test it, who does the work, where tests run, and what has to be true before you ship.

Writing one takes seven steps: learn what's changing, set the scope, rank flows by risk, choose the approach, plan environments and data, assign owners and exit criteria, then get it approved. Most test plans fit on a page or two. Skip to the test plan template if that's all you need; it's plain Markdown, ready to paste into a doc, a wiki page or your repo.

Want the plan written, and the tests behind it built and maintained for you? QA Wolf's AI agents map your app's pages, actions and flows from your users' point of view and draft the test plan from that map. Then they build and maintain the tests behind it, and ask your team when a flow's intent is unclear. 7Shifts is a perfect example. QA Wolf gave it a comprehensive test plan, and each developer got back the day a sprint that used to go to writing test cases. Book a demo to see QA Wolf plan yours.

What is a test plan?

A test plan is a document that sets the scope, approach, environments, owners, schedule and exit criteria for testing a release, project or feature. It turns "someone should test this" into a list of what gets tested, in what order, by whom, and when testing is done.

A good test plan answers five questions:

• What are you testing, and what aren't you? The features, user flows and platforms in scope, and what's left out.
• How will you test it? Which kinds of testing, and which checks are manual or automated.
• Where will tests run, and with what data? Environments, browsers, devices, accounts and test data.
• Who does what, by when? Owners and dates.
• How do you know you're done? Entry and exit criteria anyone can check.

A test plan is a working document, with test cases, results and bug reports hanging off it, and it changes when the release does.

Who writes a test plan?

A QA lead or test manager usually writes the test plan, with input from the engineers, product manager and designers who know what's changing. On teams without QA staff, it falls to an engineering lead or the developer who owns the feature.

The plan is one document, but the tests it calls for are ongoing work, since someone has to write them, run them on every release, investigate failures and fix tests when the product changes. Teams that don't want to staff that work hand it to QA Wolf's AI agents. The agents write, run and maintain the tests, investigate every failure, fix broken tests and file real bugs, and come to your team directly when they need an answer.

What should a test plan include?

A full test plan includes its scope, objectives, approach, environments, roles, schedule, entry and exit criteria, risks, deliverables and approvals:

• Scope: the features, user flows, platforms and integrations being tested, plus a list of what's out of scope and why.
• Objectives: what testing has to show before release, such as "customers can pay with every supported method" or "existing reports still match their numbers."
• Approach: the kinds of testing you'll run (for example smoke, functional, regression and end-to-end testing), which checks are automated and which are manual, and the tools.
• Test environment and data: where tests run, which browsers and devices, and the accounts, roles, seeded data and third-party sandboxes tests need.
• Roles and responsibilities: who writes, runs and reviews tests, who triages failures and who approves the release.
• Schedule: when testing starts, when the build freezes and when you ship.
• Entry and exit criteria: what must be true before testing starts (the build is deployed and smoke tests pass) and before it ends (every priority 1 flow passes and no critical bugs are open).
• Suspension and resumption criteria: when to stop testing, such as a broken environment or a build that fails smoke tests, and what has to happen before testing restarts.
• Risks and contingencies: what could derail testing, such as a late build or an unreliable payment sandbox, and the fallback for each.
• Deliverables: test cases, run results, bug reports and a short sign-off note.
• Approvals: who signs off on the plan, and who signs off on the release.

Most teams write something much looser than this list, often just the scope, the flows to test in priority order, where tests run, who owns them and what has to pass before release. Start with those (the simple template below has them), and add the other sections only when a release needs them.

How do you write a test plan?

You write a test plan in seven steps, from learning what's changing to getting sign-off. Keep each section short enough that people read it before a release.

1. Learn the product and what's changing

Read the specs, tickets and designs for the release, then ask the product manager or engineering lead to walk you through the product. Note how features depend on each other, and anything that makes testing awkward: feature flags, emails and text messages, payments, user roles, third-party services.

2. Set the scope

List the features and user flows in scope, and the platforms: browsers, devices and operating system versions. Then write down what's out of scope and why. An explicit out-of-scope list stops the argument later, when a bug turns up somewhere nobody tested.

3. Rank flows by risk

To decide what to test first, and most deeply, rank each flow by how many users touch it, what a failure would cost (revenue, data, trust) and how much its code is changing. Sign-up, login, checkout and anything that moves money usually come first. Check past incidents and support tickets too: they show where bugs have already reached customers.

Include the unhappy paths, such as a declined card or an expired session; negative testing covers the kinds to look for. Then tag each flow "automate now," "automate later" or "manual only," as QA Wolf's test coverage plan method does.

4. Choose the approach

For each flow, decide which kinds of testing it needs, and whether each check is manual or automated. Checks that must pass on every release (smoke tests, regression tests, visual checks and end-to-end tests of every user flow, critical ones first) are worth automating. A new feature gets a person's check first, for usability and what a script can't judge, and then an automated test, so every release after it is covered. Then break each flow into test cases, one behavior each, with its expected result.

5. Plan environments, data and tools

Say where tests run (a staging environment, preview deploys for pull requests, smoke checks in production), on which browsers and devices, and what each test needs: user accounts, seeded data, and payment and email sandboxes. Give each test its own data so tests don't collide when they run at the same time. Name the tools: the test framework, the CI system that runs it, and where bugs get filed.

6. Assign owners, dates and exit criteria

Name who writes, runs and reviews tests, who triages failures and who decides the release can go. Add the dates: when testing starts, when the build freezes, when you ship. Then write entry and exit criteria as checks anyone can verify, for example "every priority 1 flow passes in Chrome, Safari and Firefox, and no critical or high-severity bugs are open."

7. Review, approve and keep it current

Share the plan with engineering, product and whoever signs off the release, and get explicit approval on scope and priorities. Disagreement about what needs coverage is cheaper to settle now than after a bug ships. Then keep the plan current: update it when the scope changes, after an incident, and before the next release.

Test plan template (copy and paste)

There are two versions to copy into a doc, a wiki page or a Markdown file in your repo. The simple one covers the five things every plan needs, and it's all most teams use. The expanded one adds objectives, approach, schedule, suspension criteria, risks, deliverables and approvals, for releases that need formal sign-off or span several teams. Delete any section that doesn't apply.

Simple test plan template

# Test plan: [Project or release name]

Owner: [Name, role]
Last updated: [Date]

## Scope
In scope: [Features, user flows, browsers and devices]
Out of scope (and why): [Feature or area]: [Reason]

## Flows to test, in priority order
1. [Flow] (P1): [Why it matters]
2. [Flow] (P2): [Why it matters]

## Where tests run
- Environments: [Staging URL, preview deploys]
- Accounts and data: [Test users, roles, seeded data]

## Owners
- Writes and maintains tests: [Name or team]
- Triages failures and approves the release: [Name]

## Done when
- [Every P1 flow passes; no open critical bugs]

Expanded test plan template

# Test plan: [Project or release name]

Owner: [Name, role]
Last updated: [Date]

## 1. Scope
In scope:
- [Feature or user flow]
- [Platforms: browsers, devices, OS versions]

Out of scope (and why):
- [Feature or area]: [Reason]

## 2. Objectives
- [What testing has to show before release]

## 3. Approach
- Kinds of testing: [Smoke, functional, regression, end-to-end, accessibility, performance]
- Automated: [Flows and checks]
- Manual: [New features, checked by a person before they're automated; exploratory sessions]
- Tools: [Test framework, CI, bug tracker]

## 4. Flows to test, in priority order
1. [Flow] (P1): [Why it matters]
2. [Flow] (P2): [Why it matters]

## 5. Environments and test data
- Environments: [Staging URL, preview deploys]
- Browsers and devices: [List]
- Accounts and data: [Test users, roles, seeded data]
- Third-party services: [Payment, email or SMS sandboxes]

## 6. Roles
- Owns this plan: [Name]
- Writes and maintains tests: [Name or team]
- Runs tests and triages failures: [Name or team]
- Approves the release: [Name]

## 7. Schedule
- Testing starts: [Date]
- Build freeze: [Date]
- Release: [Date]

## 8. Entry and exit criteria
- Entry: [Build deployed to staging; smoke tests pass]
- Exit: [Every P1 flow passes; no open critical or high-severity bugs]

## 9. Suspension and resumption
- Stop testing if: [Environment down; smoke tests fail]
- Resume when: [Condition]

## 10. Risks and contingencies
- [Risk]: [Fallback]

## 11. Deliverables
- [Test cases, run results, bug reports, sign-off note]

## 12. Approvals
- [Name, role]: [Approved on date]

Test plan example: a checkout redesign

A short, filled-in version for a web store shipping a new one-page checkout:

# Test plan: One-page checkout (release 4.2)

Owner: QA lead
Last updated: Nov 9, 2026

## 1. Scope
In scope:
- New checkout: cart, shipping, payment, order confirmation
- Saved cards, guest checkout, promo codes
- Chrome, Safari and Firefox on desktop; Safari on iPhone

Out of scope (and why):
- Admin order screens: unchanged in this release
- Load testing: in the platform team's own plan

## 2. Objectives
- Customers can buy with every supported payment method in every browser in scope
- Order history, refunds and receipts work as before

## 3. Approach
- Automated end-to-end tests for every P1 and P2 flow, run on each pull request and nightly
- Existing regression suite for cart, account and order history
- One manual exploratory session on the new layout before release

## 4. Flows to test, in priority order
1. Buy with a saved card (P1): most orders use one
2. Buy as a guest with a new card (P1): first-time buyers
3. Declined card shows an error and creates no order (P1)
4. Valid promo code applies; expired code is rejected (P2)
5. Change the shipping address during checkout (P3)

Outline for flow 3 (Arrange-Act-Assert):
- Arrange: log in as a new test user; add one item to the cart; open checkout
- Act: pay with the payment provider's test card for a declined payment
- Assert: "Your card was declined" appears; no order is created; the item is still in the cart

## 5. Environments and test data
- Staging, plus a preview deploy for each pull request
- A new test user for every run; payment provider in test mode

## 6. Roles
- Owns this plan, triages failures: QA lead
- Fixes bugs, reviews outlines: checkout engineers
- Approves the release: engineering manager

## 7. Entry and exit criteria
- Entry: build on staging; smoke tests pass
- Exit: flows 1 to 4 pass in every browser in scope; no open critical or high-severity bugs

## 8. Risks and contingencies
- Payment sandbox outage: rerun payment tests before filing a bug

What are the types of test plans?

The common types of test plan are a master test plan, level test plans and type-specific test plans. A small team may need only one plan per release; large programs may use all three.

• Master test plan: one plan for a whole product or large project. It sets the shared scope, standards, tools and schedule that every team's plan follows.
• Level (or phase) test plans: one for each level of testing, such as unit, integration, system or acceptance testing, each with its own owners and criteria.
• Type-specific test plans: one for a kind of testing that needs its own tools and people, such as performance, security, accessibility or regression testing.

Agile teams often keep a short plan per release or sprint, under a living master plan, instead of one large document written up front.

How is a test plan different from a test strategy or a test case?

A test strategy sits above a test plan, and test cases sit below it. The strategy sets how you test in general, the plan applies it to one release, and each test case checks one behavior.

Test plan vs test strategy

A test strategy sets how a team or product tests in general: the levels and kinds of testing, the tools, the standards and how much gets automated, and it changes rarely. A test plan applies that strategy to one release or project, with its own scope, people, dates and exit criteria. Small teams often fold the strategy into a short "Approach" section of each plan.

Test plan vs test case

A test plan covers a whole release or project, meaning what gets tested, how, by whom and when, while a test case covers one behavior: the setup, the steps and the expected result, such as "a declined card shows an error and creates no order." The plan lists the flows to test, and each flow breaks down into test cases.

What are the most common test plan mistakes?

Most test plans fail the same few ways:

• Too long to read. If the plan runs to 30 pages, nobody checks it before a release. Cut anything that doesn't change what gets tested.
• No out-of-scope list. Without one, everyone assumes their area was covered.
• Every flow is priority 1. Rank flows so the tests built and run first are the ones that matter most.
• Exit criteria nobody can check. Write each one with a yes-or-no answer, such as "every P1 flow passes and no critical bugs are open."
• Written once, never updated. The product changes every sprint, so review the plan before each release and after each incident.

How does QA Wolf build a test plan?

Sign up for QA Wolf, tell the agent "build me a test plan," and you get one. The agent opens a browser on your app, explores each feature and maps your end-to-end workflows by feature or product area, writing each one up as a plain-English outline in Arrange-Act-Assert form. The map shows where you already have coverage and where you don't.

You can steer it three ways:

• Let it explore on its own. The agent works through each feature and documents the workflows it finds.
• Start from your existing test plan. Give it a CSV, JSON, Markdown, plain-text or YAML file, and the agent replicates the tests in it and recommends the ones you're missing.
• Show it a flow. Take control of the browser and click through a workflow while the agent watches.

You review the plan, change or drop any flow and pick which ones to automate. The agent then builds, runs and maintains those tests, and asks your team when a flow's intent is unclear. When you ship something new, ask the agent to explore the change, and it updates the plan and the affected tests.

Teams that would rather QA Wolf run all of this for them use its full service, which builds the plan with your team in a kick-off and a product tour before automating anything (how full-service onboarding works).