Test plan: [Release or project]

Replace the blue placeholders and delete the grey notes as you go. Fill in the scope and the exit criteria first: they are what approvers read most closely. For a small change, use the one-page version at the end instead.

Plan ID	[TP-project-version]
Version	[1.0]
Status	[Draft / in review / approved]
Owner	[Name, role]
Approvers	[Names and roles]
Requirements	[Link or document ID]
Last updated	[Date]

Introduction

Two or three sentences: what the release changes, and what testing must show.

[Release or project] [what it changes]. Testing must show that [the things that must be true when it ships].

Scope

Every line in the second table needs a reason. That list is where later surprises come from.

In scope	Notes
[Feature, screen or interface]	[What exactly is covered]
[Feature, screen or interface]	[What exactly is covered]
[Feature, screen or interface]	[What exactly is covered]

Out of scope	Reason
[Feature, platform or kind of testing]	[Why it isn't tested this time]
[Feature, platform or kind of testing]	[Why it isn't tested this time]

See an example out-of-scope list

Mobile apps: they show recurring invoices read-only and have no code changes in 4.2.
Payment processing: unchanged, and covered by its own regression suite.
Load testing: volumes stay within the limits tested for 4.0.

From the Billfold 4.2 plan, an invented invoicing app. Each exclusion is a decision someone can challenge in time.

Approach

Delete the rows you don't need. Add performance or security testing if the release calls for it.

Kind of testing	How	Who	Tools
Regression	[Automated suite, when it runs]	[Name]	[Tool]
Scripted	[Cases built from the risk table]	[Names]	[Test management tool]
Exploratory	[Number and length of sessions, and their focus]	[Names]	[Notes template]
Accessibility	[Standard and level, such as WCAG 2.2 AA; keyboard and screen reader]	[Name]	[Tools]
User acceptance	[Who tests, with which scenarios]	[Names]	[Where results go]

Test depth by risk

One row per change. High-risk rows get the deepest testing, go first in the schedule and appear in the exit criteria.

Change	If it fails	Risk	How it is tested
[Feature or change]	[What would go wrong for users]	[High / medium / low]	[Cases, sessions or checks]
[Feature or change]	[What would go wrong for users]	[High / medium / low]	[Cases, sessions or checks]
[Feature or change]	[What would go wrong for users]	[High / medium / low]	[Cases, sessions or checks]

Entry and exit criteria

Testing starts when

[The build or version is deployed to the test environment]
[The smoke test passes]
[Test data and accounts are ready]
[Test cases are reviewed by the product owner]

Testing is complete when

[Every high-risk case has passed]
[At least N% of planned cases have run]
[No severity 1 or 2 defects are open]
[Every open severity 3 defect has a fix date or is accepted in writing, by name]
[Acceptance testing is signed off]

Numbers, not adjectives. “No open severity 1 or 2 defects” can be checked. “Quality is acceptable” can't. Two people reading the criteria should reach the same verdict.

Suspension and resumption

Pause testing if: [a blocking failure, such as sign-in or the main workflow failing in the test environment]
Resume when: [a new build passes the smoke test]

Environments and test data

Environment	[Name and address of the test environment]
Browsers and devices	[Versions and models]
Test accounts	[How many, which roles, who creates them]
Test data	[Source, how it is anonymized, date of the copy]
Other services	[Sandboxes, test inboxes, stubs]

Roles

Role	Name	Responsible for
QA lead	[Name]	[The plan, daily status, the summary report]
Testers	[Names]	[Areas or test cases]
Developer on triage	[Name]	[Reproducing and fixing defects]
Product owner	[Name]	[Scope, accepting known defects, sign-off]
Acceptance testers	[Names]	[Business scenarios]

Schedule

Milestone	Date	Owner
Test cases ready	[Date]	[Name]
System testing	[Start – end]	[Name]
Acceptance testing	[Start – end]	[Name]
Go/no-go meeting	[Date]	[Name]
Release	[Date]	[Name]

Defects

Severity	Meaning	Example
1	[Wrong results or lost data, no workaround]	[Example from this product]
2	[A main task fails, with a workaround]	[Example from this product]
3	[A minor task fails or behaves oddly]	[Example from this product]
4	[Cosmetic]	[Example from this product]

Logged in: [tracker, with steps to reproduce]
Triage: [when it happens and who attends]

Risks and contingencies

Risks to the testing itself: environments, people, dates, outside services.

Risk	Contingency	Owner
[What could derail testing]	[What you will do if it happens]	[Name]
[What could derail testing]	[What you will do if it happens]	[Name]

Deliverables

Test cases: [where they live]
Status notes: [how often, and where they are posted]
Defect list: [link]
Test summary report: [date, and who receives it]

See the test case format

TC-RI-014: A monthly schedule set to the 31st creates an invoice on the last day of a 30-day month.

Priority and requirement: High · PRD-118, R4

Preconditions: Test customer Harbor Florists, monthly from 31 March, $120 plus 8% tax. The staging clock reads 29 April.

Set the staging clock to 30 April, 00:05.
Run the scheduler job.
Open Invoices and filter by Harbor Florists.

Expected result: One invoice dated 30 April for $129.60, status Sent. No invoice on 1 May.

Traces to: the plan's scope (monthly dates) and the High-risk row Monthly invoice dates; every high-risk case must pass before the go/no-go.

Keep test cases in your test management tool or a spreadsheet, and link to them from this plan.

Approvals

Name	Role	Version approved	Date
[Name]	[Product owner]	[1.0]	[Date]
[Name]	[Engineering lead]	[1.0]	[Date]
[Name]	[QA lead]	[1.0]	[Date]

Version history

Version	Date	What changed and why
[1.0]	[Date]	[First approved version]

One-page version

For a sprint, a hotfix or a small feature: delete everything above and keep these six lines. Go back to the full plan when the change carries real risk (money, data, security), depends on another team or system, or needs several people to coordinate testing and sign-off.

What changes	[The change, in one sentence]
What could go wrong	[The failures that would matter]
What we'll test	[Cases, devices, data]
What we won't	[And why]
Done when	[Exit criteria, as numbers]
Who	[Tester and approver]

Before you send it for approval

Every out-of-scope line has a reason
Entry and exit criteria are numbers someone else could check
Every high-risk change appears in the exit criteria
Every section, environment and kind of testing has an owner
Test data and accounts have an owner and a date
Dates in the schedule don't conflict with the go/no-go meeting
Help pages and release notes for changed screens are in scope
The plan links to the requirements and the test cases instead of copying them