Template
Test case template
A copyable test case template with the fields that make a run repeatable: preconditions, exact test data, per-step expected results, and a recorded outcome.
A test plan template that fits on one page
A test plan states what will be tested, what will not, how, in which environment, by whom, and what has to be true before testing starts and before it is called complete. The entry and exit criteria are the part that matters most: without them, testing ends when the schedule runs out rather than when the software is ready.
- Template
- 9 fields, explained
- Updated
Test plans have a reputation for being long documents nobody reads, and the reputation is often earned. The formal standard exists for contexts that require it, but most teams need a page: enough structure that the release decision has a stated basis, short enough to be revised when the plan changes.
In the template
- Scope
- What we are testing against
- Approach
- Entry criteria
- Exit criteria
- Environments and data
- Roles
- Risks
- Schedule
Test plan template, ready to copy
Copy it as it is. There is no email step, and nothing on this page is behind one.
# Test plan: [release or feature] ## 1. Scope In scope: Out of scope: ## 2. What we are testing against Requirements or acceptance criteria: Build or version: Environment: ## 3. Approach Types of testing to run (functional, regression, compatibility, accessibility, performance): What is automated and what is manual: ## 4. Entry criteria What must be true before testing starts. ## 5. Exit criteria What must be true before testing is called complete. Include the defect threshold: which severities block release. ## 6. Environments and data Environment: Test data, and how it is created or reset: ## 7. Roles Who tests what. Who accepts. ## 8. Risks Known risks, and what we will do about each. ## 9. Schedule Start, end, and the checkpoints in between.
# Test plan: promo codes at checkout ## 1. Scope In scope: checkout and payment, including the basket summary and the order confirmation. Out of scope: the admin reporting screens, because nothing in them changed this release. ## 2. What we are testing against Requirements or acceptance criteria: PROD-412, nine criteria. Build or version: 2.14.0-rc3 Environment: staging ## 3. Approach Types of testing to run: functional against the nine criteria, regression around the basket, compatibility on Safari and Chrome because the discount line is rendered in the browser, and an accessibility pass on the new promo form. What is automated and what is manual: the regression suite is automated. The nine criteria and the accessibility pass are manual this time, because the form is new. ## 4. Entry criteria The release candidate is deployed to staging, the smoke suite is green, and the test data has been reset. ## 5. Exit criteria Every planned case run. No blocker and no major open. Include the defect threshold: blocker and major block release. Remaining minors are listed and accepted by the product owner, by name. ## 6. Environments and data Environment: staging Test data, and how it is created or reset: the August seed, restored by the nightly job. Promo code SPRING20, twenty percent, no minimum, expiring 2027-01-01. ## 7. Roles Who tests what: QA runs the nine criteria and the accessibility pass. The two engineers on the story run the regression suite. Who accepts: the product owner for PROD-412. ## 8. Risks The discount is calculated in the basket and again in the order total, and only one of the two was changed. Response: a case that compares both on the same order. Safari is not on the team's machines. Response: one booked session on a real device before exit criteria are assessed. ## 9. Schedule Start 2 September, end 5 September, with a checkpoint on the 3rd after the first regression run.
The template below is that page. The section doing the real work is exit criteria, because it is the one that turns testing complete from a feeling into a claim somebody can check.
What each field is for
Scroll the table sideways for the examples.
| Field | Why it earns its place | Example |
|---|---|---|
| Scope | What is being tested and, explicitly, what is not. The out-of-scope list is what prevents the argument after release about whether something was ever going to be checked. | In: checkout and payment. Out: the admin reporting screens, unchanged this release. |
| What we are testing against | The requirements, acceptance criteria, build number and environment. Testing needs a reference to compare against, or it produces opinions. | Acceptance criteria in PROD-412, build 2.14.0-rc3, staging. |
| Approach | Which kinds of testing will run, and which are automated versus manual. This is where non-functional testing gets remembered or forgotten. | Functional, regression suite, Safari and Chrome compatibility, accessibility pass on the new form. |
| Entry criteria | What must be true before testing starts. Usually a deployed build that passes the smoke test, with a stable environment. | RC deployed to staging, smoke test green, test data reset. |
| Exit criteria | What must be true before testing is complete, including which severities block release. This is the section that makes the release decision evidence-based. | All planned cases run, zero open blockers or majors, known minors listed and accepted. |
| Environments and data | Where testing happens and how the data gets there. Undefined test data is the most common cause of tests that pass once and fail the next day. | Staging, seeded from the anonymised fixture set, reset before each cycle. |
| Roles | Who tests what, and who accepts. Acceptance is a named person, because a plan where everybody accepts is a plan where nobody does. | QA runs the suite, engineering fixes, the product owner accepts. |
| Risks optional | What could go wrong with the plan, and what you will do about each. A risk with no response is a note, not a plan. | The payment sandbox is rate-limited: batch the payment cases and run them first. |
| Schedule optional | Start, end and the checkpoints between. Mostly useful for making it visible when the window shrinks and the exit criteria have not moved. | Cycle 1 Mon to Wed, fixes Thu, cycle 2 Fri. |
A test plan scope that decides nothing, and one that does
Not this
In scope: the new promo code feature. Out of scope: n/a
This instead
In scope: checkout and payment, including the basket summary and the order confirmation. Out of scope: the admin reporting screens, because nothing in them changed this release.
A scope nobody could disagree with has not been written. The first version reads like agreement and holds none: it does not say whether the basket summary is being tested, and an empty out-of-scope line excludes nothing, so anything found anywhere is inside it. The second names a boundary somebody could push back on, which is what makes it a decision rather than a heading, and it gives the exclusion a reason, so the reason can be re-checked on the release where it stops being true.
Exit criteria are the section that matters
Every other section describes intent. Exit criteria describe a decision, and they are what stop testing from ending because the date arrived. Write them as conditions somebody else can check: all planned cases executed, no open blockers or majors, remaining minors listed and explicitly accepted by a named person. A plan whose exit criterion is that testing is finished has not stated anything.
The out-of-scope list is worth more than the in-scope one
What is being tested is usually obvious from the release. What is not being tested is the part everybody assumes differently, and the assumption surfaces after a defect ships in an area nobody checked. Writing the exclusions down converts that from a recrimination into a decision that was made in advance, visibly, by people who could have chosen otherwise.
Keep it to a page so it stays true
A plan is only useful while it matches what the team is doing, and a long document stops matching within days because revising it is a chore. The short version gets updated when the scope changes, which means the version on the screen is the one being followed. A thorough plan that is three revisions stale is worse than a brief one that is current.
A sample test plan, filled in for one release
A blank template shows the shape. A sample plan shows the sections constraining each other, which is the part that is hard to guess. Take a release that adds promo codes to checkout. Scope is checkout and payment, with the admin reporting screens named as out of scope because nothing in them changed this time. Testing runs against the acceptance criteria in PROD-412, on build 2.14.0-rc3, in staging, which is what makes a later disagreement about intended behaviour resolvable rather than a matter of memory. The approach falls out of that scope: functional cases for the new code, the regression suite around the basket, Safari and Chrome because the discount line is rendered in the browser, and an accessibility pass on the new form. Entry criteria are the release candidate deployed to staging, a green smoke test, and test data reset. Exit criteria are every planned case run, no open blocker or major, and the remaining minors listed and accepted by the product owner, named. Each of those lines is a decision that could have been made differently, and that is what an example carries and an empty form does not.
Common questions
What should a test plan include?
Scope with an explicit out-of-scope list, what you are testing against, the approach, entry and exit criteria, environments and test data, roles including who accepts, and known risks. Entry and exit criteria are the sections that make the release decision checkable.
What is the difference between a test plan and a test case?
A test plan is the plan for a release or feature: what will be tested, how, by whom and to what standard. A test case is one specific check with steps and an expected result. A plan describes the work; cases are the work.
Who writes the test plan?
Usually a QA lead or whoever owns testing for the release, agreed with engineering and the product owner. The acceptance section in particular needs the agreement of the person named in it, since it commits them to a decision.
What is the difference between a test plan template and a sample test plan?
A template is the empty structure: the headings, in order, with nothing decided. A sample is one release's answers written into it, which is what shows how much specificity each line needs. Scope filled in as testing the new feature is a template still pretending to be a plan; scope filled in as checkout and payment, with the reporting screens excluded because they did not change, is a decision somebody can disagree with.
Terms used on this page
Why the work behind it is hard
More templates
-
Template
UAT test plan template
A copyable UAT test plan template: scope, who signs off, the business scenarios to run, entry and exit criteria, and how a failure gets recorded.
Template
Test strategy template
A copyable test strategy template with a filled-in example: product risks, test levels, environments, tools, roles, entry and exit rules, and review.
Or skip the template and capture the fields automatically.
Environment, console and network attach themselves, on the free plan.