Test plan template: a copyable outline with a worked example
Test plan template: a copyable outline with a worked example
A test plan answers four questions before testing starts: what you will test, how, who does it, and what has to be true before the release can ship. Copy the template below into your own document, fill in each section, and delete the ones that do not apply to your project. A filled-in example for a single release follows it.
The template
Copy everything in the box. Each line in square brackets is a prompt to replace with your own text.
TEST PLAN
1. Document details
Project: [product or project name]
Release or version: [e.g. 2.4]
Plan version and date: [e.g. v1, 2026-10-26]
Owner: [person responsible for this plan]
Approvers: [who signs off before release]
2. Objectives
[Two or three sentences: what this round of testing must prove.]
3. Scope
In scope: [features, platforms, user roles, integrations]
Out of scope: [what you will not test, and why]
4. Test items and requirements
[List each feature or change, with its ticket or requirement ID.]
5. Test approach
Test types: [functional, regression, exploratory, API, accessibility,
performance, security: keep only what applies]
Manual vs automated: [what runs by hand, what runs in CI]
Test case source: [existing suite, new cases, generated from tickets]
6. Entry criteria
[What must be true before testing starts, e.g. build deployed to
staging, test data loaded, smoke test passing.]
7. Exit criteria
[What must be true before release, e.g. all planned cases run,
no open critical or high bugs, pass rate above an agreed level.]
8. Suspension and resumption
Pause testing if: [e.g. login or checkout is broken on the build]
Resume when: [e.g. a fixed build passes the smoke test]
9. Environments and test data
Environments: [URLs, devices, browsers, OS versions]
Test data: [accounts, seed data, payment sandbox, how it is reset]
10. Roles and responsibilities
[Name: role, e.g. test lead, tester, developer on call, product owner]
11. Schedule
[Start date, test cycles, bug-fix window, regression run, sign-off date]
12. Risks and mitigations
[Risk: what could delay or weaken testing. Mitigation: what you will
do about it.]
13. Defect management
Where bugs are logged: [tool and project]
Severity levels: [critical, high, medium, low, with one line each]
Triage: [who triages, how often]
14. Deliverables
[Test cases, run results, bug reports, test summary report]
15. Sign-off
[Approver names, decision (go / no go), date]What goes in each section
Most sections are self-explanatory. These are the ones teams most often get wrong.
Scope. Write the out-of-scope list as carefully as the in-scope one. "We are not testing the admin panel this release because it did not change" saves an argument later, when someone asks why a bug there was missed.
Entry and exit criteria. Make them checkable. "Quality is acceptable" cannot be checked. "No open critical bugs and every planned case run" can. Exit criteria are what the go or no-go conversation at the end is about, so agree them with the approvers before testing starts, not after.
Risks. Name real risks for this release, not generic ones. "The payment provider sandbox is often down on weekends" is useful. "Requirements may change" is true of every project and tells nobody what to do.
Defect management. Define severity in one line per level, with an example. Without that, two testers will file the same bug as "high" and "medium" and the exit criteria stop meaning anything.
Worked example: a checkout release
This is an example for an imaginary online shop. Use it to see how much detail each section needs, not as a plan to copy word for word.
1. Document details. Project: web shop. Release: 2.4, new checkout. Plan v1, owner: the QA lead. Approvers: product owner and engineering lead.
2. Objectives. Show that customers can buy with the new one-page checkout on desktop and mobile, that saved addresses and discount codes still work, and that nothing in the old order history broke.
3. Scope. In scope: one-page checkout, card and PayPal payments, discount codes, guest checkout, order confirmation email. Out of scope: the admin order screens (unchanged this release) and the mobile app (separate release).
4. Test items. The six checkout tickets in the release, plus the existing regression suite for cart and order history.
5. Test approach. Functional testing of each ticket by hand, the existing automated regression suite in CI, one exploratory session per payment method, and an accessibility pass on the checkout form with a keyboard and a screen reader.
6. Entry criteria. Release candidate deployed to staging, payment sandbox connected, test accounts with saved cards and addresses created, smoke test green.
7. Exit criteria. Every planned case run. No open critical or high bugs. Any open medium bugs reviewed and accepted by the product owner. Regression suite green on the final build.
8. Suspension and resumption. Stop if payment fails for every method on a build. Resume when a new build passes the smoke test.
9. Environments and test data. Staging. Latest Chrome, Safari and Firefox on desktop; Safari on iOS and Chrome on Android. Five test accounts, sandbox cards for success, decline and 3-D Secure, and three discount codes (percentage, fixed amount, expired).
10. Roles. QA lead: plan, triage, sign-off report. Two testers: execution and exploratory sessions. One developer on call each test day. Product owner: accepts open medium bugs.
11. Schedule. Three days of testing, two days for fixes, one day for the regression run and sign-off.
12. Risks and mitigations. The payment sandbox has been unreliable: book the test window with the payments team and keep a mocked payment path for functional checks. Only one tester knows the discount rules: pair the second tester on those cases on day one.
13. Defect management. Bugs logged in the team's bug tracker with steps to reproduce, expected and actual result, and a screenshot. Critical: no one can complete a purchase. High: a payment method or a common path fails. Medium: a workaround exists. Low: cosmetic. Triage every morning with the developer on call.
14. Deliverables. Test cases linked to the six tickets, run results per build, bug reports, and a one-page summary for the approvers.
15. Sign-off. Product owner and engineering lead, go or no-go recorded with the date and the build number.
Test plan or test strategy?
A test strategy describes how an organisation or product tests in general: the levels of testing, the tools, the standards. It changes rarely. A test plan applies that strategy to one project or release, with dates, names and scope. Most small teams need only the plan, with a short approach section where a strategy document would otherwise sit.
Keeping the plan connected to the testing
A plan in a document goes stale the moment testing starts, because the cases, results and bugs live somewhere else. If you use BugBoard, the parts of the plan that change during testing sit next to each other: test cases in suites and folders, test runs with pass, fail and blocked results, bugs linked to the cases that found them, and releases that track coverage and quality per release. BugBoard also works with any MCP-compatible AI coding tool (MCP setup), so you can ask your assistant to draft a structured test plan from a spec, or to give a go or no-go recommendation for a release based on pass rates, open bugs, blockers and coverage. BugBoard is free while in early access, with no credit card required.
If you would rather have experienced testers write and run the plan for you, that is what BetterQA does.