QA Process

Test Plan Examples.

A copy-paste test plan template — simple and detailed — plus worked examples for agile, web, mobile and API testing, so you can scope any release without staring at a blank page.

TemplateQA · Senior QA · Lead12 min

When to use it

Reach for a test plan when the cost of a coverage gap is higher than the cost of writing one — anything cross-team, payment- or data-sensitive, regulated, or big enough that "we'll just test it" leaves room for argument at sign-off. Skip the ceremony for a one-line copy fix.

Who uses it

QA engineers writing it, senior QA and leads reviewing scope and risk, and product / engineering signing off that the plan matches the release.

On this page13 sections

WHAT IS A TEST PLAN

A test plan is a short document that says how you'll test a piece of work: what's in scope, how you'll approach it, who does what, and how you'll know testing is done. It's the shared answer to the question "what does 'tested' mean for this release?"

It is not a list of test cases — those live in your test management tool — and it's narrower than a test strategy, which is the standing approach a plan instantiates for one feature or release. Think of the plan as the working agreement for this specific piece of work.

WHEN DO YOU NEED ONE

Write a test plan when the cost of a gap is higher than the cost of the plan. That usually means anything cross-team, payment- or data-sensitive, regulated, or large enough that an informal "we'll just test it" leaves room for argument when it's time to ship.

Skip the ceremony for a one-line copy change or a trivial bug — a sentence in the ticket is enough. The goal is a plan sized to the risk, not a plan for its own sake. When in doubt, fill the simple template below; it takes ten minutes and prevents the Friday-afternoon scope debate.

TEST PLAN VS TEST STRATEGY

Test planTest strategy
AltitudeOne feature or releaseThe whole team or product
LifespanLives and dies with the releaseStable for months
OwnerQA engineer on the workQA lead / manager
AnswersHow do we test this?How do we test, in general?
ExampleGuest checkout v2.4 planOur standing automation + risk approach

WHAT A GOOD TEST PLAN INCLUDES

A good plan answers four questions and little more: what are we testing, how deeply, who does what, and how do we know we're done. Every field below earns its place by serving one of those — if a section doesn't, cut it. A plan no one reads is worse than no plan.

The two templates that follow share the same 17 fields. The simple version gives you a one-line prompt per field for everyday work; the detailed version fills those same fields for a realistic multi-team release. You won't always need every field — treat the unused ones as prompts, not obligations.

Scope beats detail

The two highest-value fields are Scope and Out of scope. An explicit out-of-scope list prevents the late-Friday argument about whether something was ever meant to be covered — it's the cheapest field to write and the most valuable at sign-off.

Exit criteria are the contract

Vague exit criteria ("testing complete") make sign-off a judgement call. Concrete ones ("0 open Critical/High, all P1/P2 passed, payment paths green") let anyone read the status and know whether you can ship.

SIMPLE TEST PLAN TEMPLATE

simple-test-plan.md
MARKDOWN
# Test plan: <feature / module>

## Project name
The product or app this work belongs to.

## Feature/module
The specific feature, story, or area under test.

## Objective
One sentence: what testing this feature must prove.

## Scope
Bullet list of what you will test.

## Out of scope
What you will deliberately not test, and why.

## Test approach
How you'll test it — manual, automated, exploratory, and at what level.

## Test types
Functional, regression, accessibility, performance, etc.

## Test environments
Where you'll run it (staging URL, build, browsers/devices).

## Test data
Accounts, fixtures, and sample records you'll need.

## Roles and responsibilities
Who designs, runs, and signs off the tests.

## Entry criteria
What must be true before testing starts.

## Exit criteria
Measurable conditions that mean testing is done.

## Risks and mitigations
What could go wrong, and your plan for each.

## Defect management
Where bugs are logged and how severity is set.

## Schedule
Rough dates for design, execution, and retest.

## Deliverables
What you'll hand over (cases, reports, evidence).

## Approvals
Who signs off, and when.

DETAILED PROJECT TEST PLAN

detailed-test-plan.md
MARKDOWN
# Test plan: <release / project name>

## Project name
Product, release train, and version this plan covers.

## Feature/module
All features, services, and components in this release — list each with its
owning team.

## Objective
What this release must prove before it ships, in business terms. Tie it to the
release goal.

## Scope
Every user-facing flow and integration to be tested. Group by team or service so
coverage is auditable.

## Out of scope
Areas explicitly excluded, each with a reason and who owns it instead. This list
prevents late scope arguments.

## Test approach
Levels (unit / integration / system / UAT), the manual vs automated split per
area, and how cross-team integration testing is sequenced.

## Test types
Functional, regression, integration, performance, security, accessibility,
compatibility — note which apply to which area.

## Test environments
Each environment in the path (integration → staging → pre-prod), versions per
service, feature flags, and third-party sandboxes.

## Test data
Seed data, anonymised production-like sets, payment sandboxes, and data-privacy
constraints. Note who provisions each.

## Roles and responsibilities
A RACI-style breakdown: who designs, executes, triages, automates, and signs off
per team.

## Entry criteria
What must be true across all teams before system testing starts (builds deployed,
green smoke tests, data ready).

## Exit criteria
Measurable, per-severity thresholds and coverage targets that gate the go/no-go
decision.

## Risks and mitigations
Cross-team and technical risks scored by impact and likelihood, each with a named
owner and a mitigation.

## Defect management
Tracker, severity/priority definitions, triage cadence, and the escalation path
for blockers.

## Schedule
Phased dates: test design, per-team execution, integration/system test, UAT, and
a retest buffer. Note dependencies.

## Deliverables
Test cases, automation runs, defect reports, a test summary report, and the
sign-off record.

## Approvals
Named sign-off from QA lead, product, engineering, and any compliance
stakeholder, with dates.

AGILE SPRINT TEST PLAN

In agile teams you rarely write a full document per story. The plan lives in the work: acceptance criteria on the ticket, a one-line test approach, and a shared Definition of Done. A one-screen plan per story — or a single lightweight plan for the sprint — is usually all you need.

The fields are the same 17, just compressed. The point isn't less rigour; it's putting the rigour where it pays off (scope, risks, exit) and dropping the boilerplate that a two-week iteration doesn't earn.

Worked example — wishlist story

Story — "As a shopper I can save items to a wishlist." Sprint 23 (2 weeks).

Scope — add/remove item, list persists across sessions, 50-item cap.

Out of scope — sharing a wishlist (next sprint).

Approach — devs unit-test at the TDD level; QA runs four acceptance checks plus exploratory; a wishlist-API test is added to CI.

Risk — persistence differs for guests vs logged-in users → verify both.

Definition of Done — acceptance criteria met, automated test green, 0 open Critical/High, demoed at review.

WEB APPLICATION TEST PLAN

A web plan adds the dimensions a generic plan skips: a browser matrix, responsive breakpoints, form validation, and graceful behaviour on slow connections. The scope and exit fields look familiar; the difference is in Test environments and Test types.

Be explicit about which browsers and viewports are in and out — "works in Chrome" is not coverage, and an unstated matrix is where production surprises come from.

Worked example — account dashboard

Feature — account dashboard with filters and CSV export.

Browser matrix — Chrome, Firefox, Safari, Edge (latest and latest-minus-one).

Responsive — 360, 768, 1280, and 1920px breakpoints.

Functional — filter combinations, empty/zero-result states, CSV export accuracy.

Forms — client and server validation, error messaging, full keyboard navigation.

Accessibility — WCAG 2.1 AA on the filters and results table; screen-reader labels.

Performance — first meaningful paint under 2.5s on a throttled 3G profile.

Out of scope — IE11 (dropped), native print styling.

MOBILE APP TEST PLAN

A mobile plan lives and dies on the device and OS matrix, plus the conditions a desktop app never sees: changing network states, OS permission prompts, interruptions like calls and notifications, and the app being backgrounded and resumed.

Pick the device matrix from real usage data, not what's on your desk, and write down the OS-version range you support — that single decision drives most of the test effort.

Worked example — live order tracking

Feature — live order-tracking screen (iOS + Android).

Device matrix — iPhone SE & 15, Pixel 6, Samsung A54.

OS range — iOS 16–18, Android 12–15.

Network states — Wi-Fi, 4G, offline → online recovery, airplane mode.

Permissions — location allow/deny, background location, prompt re-request.

Interruptions — incoming call, push notification, app backgrounded then resumed.

Functional — map updates, ETA accuracy, status transitions.

Risk — battery drain from location polling → measure over a 30-minute session.

Out of scope — tablets, landscape orientation.

API TESTING TEST PLAN

An API plan has no UI, so it centres on the contract: status codes, authentication and authorisation, response schema, error handling, and idempotency. Scope is a list of endpoints and the behaviours each must honour.

Test against the published spec (OpenAPI / JSON schema) rather than the current implementation — that's what catches a breaking change before a consumer does.

Worked example — orders API

Endpoints — POST /orders, GET /orders/{id}, GET /orders.

Contract — request/response validated against the OpenAPI spec; unknown fields rejected.

Status codes — 201 create, 200 read, 400 validation, 401/403 auth, 404 missing, 409 duplicate.

Auth — bearer token required; expired/invalid token → 401; wrong scope → 403.

Schema — responses match the JSON schema; required fields present with correct types.

Data — boundary values, missing required fields, oversized payloads.

Idempotency — repeating a POST with the same idempotency key creates no duplicate order.

Out of scope — rate limiting (platform team), the GraphQL gateway.

COMMON MISTAKES

  • Listing test cases instead of an approach.

    The plan says how and how much you'll test; the cases live in your test management tool. Don't duplicate them here.

  • Skipping the out-of-scope section.

    Naming what you won't test is what stops scope creep and protects you at sign-off. It's the cheapest section to write and the most valuable.

  • Exit criteria that can't be measured.

    Replace "adequately tested" with numbers: pass rate, open-defect thresholds by severity, and coverage targets.

  • Reusing one plan for web, mobile, and API unchanged.

    Each platform fails differently — browser matrix, device and network states, contract and status codes. Relabelling a web plan for mobile misses the failures that actually happen there.

  • Writing it once and never touching it.

    Update scope and risks as the release changes. A stale plan loses trust fast — link it from the ticket so it stays in view.

  • A 12-page plan for a 2-day feature.

    Match effort to risk. For small work, the simple template filling only the fields that matter beats a detailed plan padded with N/A.

CHECKLIST BEFORE SHARING

  • Every in-scope feature maps to at least one planned test.
  • The out-of-scope list is explicit, with a reason for each item.
  • Entry and exit criteria are measurable, not adjectives.
  • Risks have a named mitigation and owner, not just a description.
  • Environment, test data, and accounts are listed and available.
  • Owners are named for design, execution, triage, and sign-off.
  • Schedule includes a buffer for retesting fixed defects.
  • Someone other than the author has reviewed the scope.