Start free

A test strategy template, with a filled-in example

A test strategy template is the outline of the standing document that says how a team tests on every release: the product risks that matter most, the test levels and types that answer them, environments, tools, roles, entry and exit rules, defect handling, what is deliberately out of scope, and when the strategy itself is reviewed. A test plan is written per release and inherits it. If a line would change when the release changes, it belongs in the plan.

  • Template
  • 11 fields, explained
  • Updated

A test strategy is the document a team writes once and every test plan inherits. It holds the rules that stay the same from one release to the next, which is why it can be short: nothing in it depends on which release comes next.

Jump to the template Start free
Watercolour of a burnt orange plumb bob hanging from a taut string, its point above a soft olive wash

In the template

  1. Purpose and scope
  2. Product risks
  3. Test levels
  4. Test types on every release
  5. Environments and test data
  6. Tools
  7. Roles
  8. Entry and exit rules
  9. Defect handling
  10. Out of scope
  11. Review

Test strategy template, ready to copy

Copy it as it is. There is no email step, and nothing on this page is behind one.

Which version of the artefact to show 
# Test strategy: [product or team]

## 1. Purpose and scope
Product, teams and platforms this covers:
Owner (one person):
Applies from:

## 2. Product risks
The failures that would cost the most, ranked. Every section below answers this list.
| # | Risk | What it costs | Answered by |
|---|------|---------------|-------------|
| 1 |      |               |             |
| 2 |      |               |             |
| 3 |      |               |             |

## 3. Test levels
| Level | What a pass proves | Who writes and runs it | When it runs |
|-------|--------------------|------------------------|--------------|
| Unit |  |  |  |
| Integration |  |  |  |
| End to end |  |  |  |
| Manual and exploratory |  |  |  |

## 4. Test types on every release
Always run:
Run on a trigger, with the trigger:

## 5. Environments and test data
Environments, and what each is for:
Known differences from production:
Test data, where it comes from and how it is reset:

## 6. Tools
Test runners, and where they run:
Where results are kept:
Where defects are reported and tracked:

## 7. Roles
Who tests what:
Who decides a release can go (one person):

## 8. Entry and exit rules
Before testing starts on any release:
Before testing is called complete on any release:
Severities that block a release:
Who may waive a rule, and where the waiver is recorded:

## 9. Defect handling
Severity scale, one line per level:
What every report carries:
Who triages, and how often:
What a fix needs before it is closed:

## 10. Out of scope
What we deliberately do not test, why, and who accepted it:

## 11. Review
What reopens this document:
Last reviewed, and what changed:
# Test strategy: clinic booking web app

## 1. Purpose and scope
Product, teams and platforms this covers: the patient booking pages and the clinic dashboard, web only. One team builds both: five developers, a QA lead, a designer and a product owner, releasing every two weeks.
Owner (one person): the QA lead.
Applies from: 2026-03-02, to every release. Each release's test plan inherits this document and records only what differs.

## 2. Product risks
The failures that would cost the most, ranked. Every section below answers this list.
| # | Risk | What it costs | Answered by |
|---|------|---------------|-------------|
| 1 | Two patients hold the same slot | A clinic turns a patient away at the door | Integration tests that send two bookings for one slot at once |
| 2 | A deposit is taken and no booking is recorded | Money moved for nothing and refunded by hand | Integration tests against the payment sandbox, including declined and timed-out payments |
| 3 | A reminder is not sent, or is sent at the wrong hour | Missed appointments and an empty slot for the clinic | Unit tests on the reminder rules, including the days the clocks change |
| 4 | Patient details are shown to the wrong clinic | Personal data exposed | Integration tests asserting clinic isolation on every endpoint |
| 5 | The booking page cannot be used on a phone or with a keyboard | Patients give up and telephone the clinic instead | Compatibility and accessibility passes on every release |

## 3. Test levels
| Level | What a pass proves | Who writes and runs it | When it runs |
|-------|--------------------|------------------------|--------------|
| Unit | Booking, pricing and reminder rules return the right answer for one input | The developer making the change | Every pull request, and a failure blocks the merge |
| Integration | The API, the database and the payment sandbox agree, including when a call fails | The developer making the change | Every pull request, and a failure blocks the merge |
| End to end | A patient can book, pay and cancel, and staff can move an appointment, in a real browser | QA writes them, developers keep them passing | Every merge to main, and on staging before a release |
| Manual and exploratory | What nobody wrote an assertion for: new screens, unusual diaries, real devices | QA, with the designer on new screens | Each release, on staging, in a session of fixed length |

## 4. Test types on every release
Always run: the end-to-end regression suite on staging. Compatibility on Chrome, Safari, Firefox and Edge at the current version and one behind, plus Safari on iOS and Chrome on Android. An accessibility check of keyboard reach, focus, contrast and headings on every public page that changed.
Run on a trigger, with the trigger: a load test on the booking endpoints when the availability query changes. A security review when sign-in, permissions or the payment flow changes. A migration rehearsal on a copy of the seed when the schema changes.

## 5. Environments and test data
Environments, and what each is for: a preview deployment per pull request, for review. Staging, for release testing. Production.
Known differences from production: staging uses the payment provider's sandbox, delivers email to a test mailbox and text messages to the provider's sandbox, and holds a smaller database. Everything else is deployed by the same pipeline.
Test data, where it comes from and how it is reset: a seed of six fictional clinics with full, empty and overlapping diaries, restored every night and on demand. No patient data is copied from production.

## 6. Tools
Test runners, and where they run: a unit test runner for unit and integration tests and a browser automation framework for end to end, both run by the CI pipeline.
Where results are kept: on the pull request for the automated suites. The release pass is recorded in the release's test plan.
Where defects are reported and tracked: through a feedback widget, which attaches the browser, the console errors and the network activity to each report. Tracked on the team's board, with severity and priority as separate fields.

## 7. Roles
Who tests what: developers write the unit and integration tests for the code they change. QA owns the end-to-end suite, the release pass on staging and the exploratory session. The designer checks new screens against the design.
Who decides a release can go (one person): the product owner, on the QA lead's written summary.

## 8. Entry and exit rules
Before testing starts on any release: the release candidate is deployed to staging by the pipeline, all three automated suites are green on that build, and the seed has been restored.
Before testing is called complete on any release: every check in the release's test plan has a result, and each defect still open is listed with an owner and accepted by the product owner, by name.
Severities that block a release: blocker and major.
Who may waive a rule, and where the waiver is recorded: the product owner only, in writing on the release ticket, with the reason. Waivers are read out at the next retrospective.

## 9. Defect handling
Severity scale, one line per level:
Blocker: a patient cannot book or pay, or personal data is exposed.
Major: a main flow works only with a workaround, or a secondary flow gives a wrong result.
Minor: cosmetic, with no effect on a task.
What every report carries: steps to reproduce, the expected and the actual result, the build, the browser and device, and a screenshot or recording.
Who triages, and how often: the QA lead and the engineering lead, every working day at 10:00. A blocker is looked at when it arrives.
What a fix needs before it is closed: verified on the build that will ship by somebody other than its author, and a regression test added at the lowest level that reproduces the defect.

## 10. Out of scope
What we deliberately do not test, why, and who accepted it: the payment provider's own card handling, which the provider tests. We test our calls to it and every failure response it can return. Browsers more than one version behind current, which the support page lists as unsupported. Native apps, because there are none. Penetration testing, which is commissioned separately once a year and is not part of a release. Accepted by the product owner.

## 11. Review
What reopens this document: a test level or tool is added or dropped, the severity scale changes, a defect reaches production that a rule here should have caught, a product change adds a risk, or a second team starts working from this document. New joiners read it in their first week and report anything that no longer matches what the team does.
Last reviewed, and what changed: 2026-09-02. Risk 4 was added when clinic groups launched and one sign-in began to cover several clinics.

The template below is that document in eleven sections, sized so a small web team can keep it to one or two pages. The filled-in version is the same strategy written for one product, a web app that clinics use to take appointment bookings, so each section shows how specific a standing rule has to be before a plan can lean on it.

The per-release document is a separate page. The strategy sets the standing entry and exit rules and the severity scale, and each test plan applies them to one release. The test plan template in this collection is that document, with the scope, the build and the schedule of a single release.

What each field is for

Scroll the table sideways for the examples.

Field Why it earns its place Example
Purpose and scope Which product, teams and platforms the strategy governs, the one person who owns it, and the date it applies from. The owner is the line that matters. A standing document with no owner is true on the day it is written and drifts from then on, because keeping it current is nobody's job. The patient booking pages and the clinic dashboard, web only. Owner: the QA lead. Applies to every release from 2026-03-02.
Product risks The failures that would cost this product the most, ranked, each with the testing that answers it. These are the standing risks, the kinds of failure the product is always exposed to. A risk that belongs to one build, such as a module rewritten for this release, goes in that release's test plan. The Answered by column is what makes the list usable: a risk with nothing in that column is a gap the team can see. 1. Two patients hold the same slot. A clinic turns a patient away at the door. Answered by integration tests that send two bookings for one slot at once.
Test levels Each level the team runs, what a pass at that level proves, who writes and runs it, and when. The owner column settles in advance whose job a failing test is, which is otherwise argued on the day it fails. Delete a row the team does not run, since a level listed and never run is a claim the document cannot support. End to end: a patient can book, pay and cancel in a real browser. QA writes them, developers keep them passing. Runs on every merge to main.
Test types on every release The types of testing no release may skip, and the types that run only when something specific changes, with the trigger named. Writing the trigger down is what stops a load test or a security review being forgotten on the release that needed it and debated on the ones that did not. Always: regression, compatibility on the browser list, accessibility on every public page that changed. On a trigger: a load test when the availability query changes.
Environments and test data The environments a build passes through and what each is for, the known differences between the last one and production, and where test data comes from. The list of differences is the part to keep honest, because a pass on staging says something about production only as far as the two are known to match. Staging uses the payment provider's sandbox and a test mailbox. A seed of six fictional clinics is restored every night. No patient data is copied from production.
Tools The test runners and where they run, where results are kept, and where defects are reported and tracked, in one line each. The section stops every release plan choosing again, and it tells a new joiner where to look on their first day. A unit test runner and a browser automation framework, run by the CI pipeline. Results on the pull request. Defects reported through a feedback widget and tracked on the team's board.
Roles Who tests what at each level, and the one person who decides a release can go. The person who collects the evidence and the person who makes the decision are named separately, so the pressure of a date does not land on whoever found the problems. Developers own unit and integration tests. QA owns the end-to-end suite and the release pass. The product owner decides, on the QA lead's written summary.
Entry and exit rules The floor every test cycle inherits: what must be true before testing starts, what must be true before it ends, which severities block a release, and who may waive a rule. A release's test plan writes its own criteria on top of these and may be stricter. Going below the floor takes a waiver with a name and a reason on it. Blocking severities: blocker and major. Every defect still open is listed with an owner and accepted by the product owner, by name.
Defect handling The severity scale with one line defining each level, what every report has to carry, who triages and how often, and what a fix needs before it is closed. The definitions are what the exit rule rests on. A rule that blocks on blocker and major decides nothing until each word has a definition two people would apply the same way. Blocker: a patient cannot book or pay, or personal data is exposed. Triage every working day at 10:00 by the QA lead and the engineering lead.
Out of scope What the team has decided not to test, with the reason and the person who accepted it: a third party's internals, browsers it does not support, platforms it does not ship on. Written down, an exclusion is a decision somebody took and can revisit. Left unwritten, it is a gap found after a defect ships. The payment provider's own card handling, which the provider tests. We test our calls to it and every failure response it can return.
Review The events that reopen the document, and a note of the last review and what it changed. Events suit a document that is meant to change rarely better than a date in the calendar does. The note is what tells a reader whether the page still describes how the team tests. Reopened when a level or a tool changes, the severity scale changes, a product change adds a risk, or a defect reaches production that a rule here should have caught.

A test strategy that fits any team, and the same one written for a product

Not this

Approach: all features will be tested thoroughly using a mix of manual and automated testing.
Quality is everyone's responsibility.
All blocking bugs must be fixed before release.

This instead

Risk 1: two patients hold the same slot. Answered by integration tests that send two bookings for one slot at once, on every pull request.
Levels: developers write the unit and integration tests for the code they change. QA owns the end-to-end suite and an exploratory session on staging each release.
The product owner decides a release can go, on the QA lead's written summary.
Blocking severities: blocker and major. Blocker means a patient cannot book or pay, or personal data is exposed.

Both are the same part of the same document. The first could be pasted into any team's strategy unchanged, which is the sign that it decides nothing: thoroughly has no measure, everyone's responsibility names no one, and blocking has no definition, so the release meeting will supply one under pressure. The second names a risk and the test that answers it, an owner for each level, one person who decides, and what blocker means. Each of those lines commits the team to something, and the next test plan can lean on it without asking anybody.

Product risks come first, because every other section answers them

A test strategy that opens with its test levels describes activity. One that opens with risks says what the activity is for. The list is short and particular to the product: for a booking app, two patients holding one slot and a deposit taken with no booking recorded rank above anything about layout. How the ranking is scored, and by whom, is covered under risk-based testing in the glossary. The last column, Answered by, ties each risk to a level or a type further down the page. A risk with an empty cell is a gap the team can now see, and a test level that answers no risk is a candidate for less effort. These are the standing risks. A risk that belongs to one release, a rewritten module or a data migration, goes in that release's plan and would be wrong here a month later.

What goes in the test strategy and what goes in the test plan

Several headings appear in both documents: roles, environments, entry and exit, risks. The strategy holds the standing version of each, and the plan holds one release's use of it. Entry and exit are the clearest case. The strategy sets the floor and the severity scale. The plan's exit criteria then name the severities that block this release, in the strategy's words, and may add to the floor. Roles work the same way: the strategy says who decides on every release, and the plan says who tests what this time. Risks split by lifespan, with the product's standing failures here and one build's hazards in the plan. The plan has its own page in this collection, the test plan template, and its fields are explained there. The glossary entry on test plan vs test strategy gives the rule for sorting any other line.

A test strategy example, filled in for one product

The filled-in version is written for a web app that clinics use to take bookings: a patient chooses a slot, pays a deposit by card and gets a reminder by email or text message. One team builds it and releases every two weeks. What the example shows is one section giving the reason for another. The first risk, two patients holding one slot, is the reason the integration row exists and the reason those tests send two bookings at once. The fourth risk, patient details shown to the wrong clinic, is why the definition of blocker includes exposed personal data, and that definition is what the blocking rule points at. The out of scope line about the payment provider is paired with what stays in scope on the same subject: the calls to the provider and every failure response it can return. Staging's differences from production are listed, so a pass there claims no more than it should. None of those lines mentions a release, which is why the next test plan can inherit all of them.

Out of scope and review are the sections that keep a test strategy true

Every other section says what the team does. These two say what it has chosen not to do, and when it will check that the document still describes the team. An exclusion with a reason can be revisited when the reason stops holding. Native apps are out of scope because there are none, and on the day one ships that line is the prompt to write its rules. Review works by event. A new test level, a change of tool, a revised severity scale, a product change that adds a risk and a defect in production that one of these rules should have caught are each a reason to open the document. A date in the calendar is a weaker one, since nothing may have changed. The document can go wrong in two directions. Edited on every release, it has release content in it that belongs in a plan. Untouched while the team's practice moved on, it describes a team that no longer exists. Recording the last review and what it changed is how a reader tells which of the two they are holding.

Common questions

What should a test strategy template include?

A test strategy template should include the document's scope and owner, the ranked product risks, the test levels with an owner for each, the test types every release runs, environments and test data, tools, roles, standing entry and exit rules, defect handling with a defined severity scale, what is out of scope, and what triggers a review. The risks, the exit rule and the severity definitions are the parts a test plan leans on hardest.

What does a test plan take from the test strategy?

A test plan takes the standing rules from the test strategy and does not decide them again: the test levels and who owns each, the severity scale, the floor for entry and exit, the environments, and who decides a release can go. The plan adds what only one release has, which is its scope, its build, its schedule and its own risks, and it records any waiver of a standing rule.

What does a test strategy example look like?

A filled-in test strategy reads as a short list of decisions particular to one product. The example on this page is for a clinic booking web app. Its first risk is two patients holding the same slot, its integration tests send two bookings at once to answer that risk, and a release is blocked by any open blocker or major defect, with each word defined in one line. An example that could be pasted into another team's document unchanged is still a template.

Is a test strategy part of a test plan?

Both arrangements are in use, and the name alone does not settle it. The contents of ISO/IEC/IEEE 29119-3:2021, the international standard for test documentation, list a test strategy as a section of the test plan, and give the organisation-level documents other names: "Test policy" and "Organizational test practices". This page uses test strategy for the standing document a team keeps across releases. Whichever name a team uses, the split that matters is the same: rules that hold on every release in one place, one release's decisions in another.

Who writes a test strategy?

Whoever leads quality for the product writes it: a QA lead where there is one, and the engineering lead where there is not. Developers supply the test levels and where the code is fragile. The product owner agrees the blocking severities and their definitions, since those commit the product owner to a decision on every release. One person is named as owner, because a shared document with no owner goes stale.

What should trigger a review of a test strategy?

A review of a test strategy is triggered by an event: a test level or a tool is added or dropped, the severity scale is revised, a product change adds a risk, or a defect reaches production that one of the rules should have caught. Each review is recorded with its date and what it changed, so a reader can tell whether the page still describes the team.

Does a small team need a written test strategy?

A team whose members already test the same way can postpone it, and a definition of done covers much of the same ground until then. Writing one becomes worthwhile when two people disagree about what that definition means, or when the same standing rules have been copied into a second test plan. The two tables, risks and levels, are enough to start with, and the other sections can be filled in as their questions come up.

How long should a test strategy be?

One or two pages is enough for a single product team. Past that length, look for release content that belongs in a plan, and for paragraphs that describe testing in general without deciding anything about this product. Each section of the template can be answered in a few lines, and the two tables carry most of the detail.

Terms used on this page

Why the work behind it is hard

More templates

  • Watercolour of a folded paper map with one burnt orange route traced across its green ground

    Template

    Test plan template

    A copyable test plan template covering scope, approach, entry and exit criteria, environments, roles and risks. The short version teams actually keep updated.

    9 fields, explained ·

  • Watercolour of a blank index card lying alone, one orange tick mark bleeding into its surface

    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.

    9 fields, explained ·

  • Watercolour of a rubber stamp resting on its side beside a dried ring of orange ink

    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.

    10 fields, explained ·

Or skip the template and capture the fields automatically.

Environment, console and network attach themselves, on the free plan.

Start free
<script src="…/widget.js" data-key="pb_pub_…">