Writing a Test Plan

Lightweight vs formal test plans

There are two very different styles out there, and you’ll likely meet both.

	Lightweight (agile)	Formal
Length	One page, often a wiki page	10 to 50 pages
Written for	A feature, sprint or release	A whole project or contract
Updated	Whenever things change	Through versioned approvals
Typical in	Startups, product teams, most apps	Banking, medical, government, outsourcing

The classic formal template comes from IEEE 829, the old “Standard for Software and System Test Documentation”. It has been replaced by the ISO/IEC/IEEE 29119 series, whose part 3 (ISO/IEC/IEEE 29119-3) covers test documentation. That’s the name you’ll see in modern contracts and audits. Both describe much the same contents: test items, features to be tested and not tested, approach, pass/fail criteria, suspension and resumption criteria (when to pause testing, for example if the build is too broken), deliverables, environment, responsibilities, schedule, risks and approvals.

The sections, one by one

Scope: in and out

List the features and platforms you will test, and just as clearly, what you won’t. “Out” doesn’t mean “unimportant”. It means “not part of this piece of work” or “someone else covers it”.

Objectives

One to three sentences on what success means, in user and business terms: “Customers can pay with Apple Pay and Google Pay and get a correct order. Nobody is charged twice or the wrong amount.” Objectives help you decide what matters when time runs short.

Approach and test types

Say which kinds of testing you’ll do and how deep. For example: scripted test casesTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary → for payment and order creation; exploratory testing sessions for the wallet sheet and interruptions; a regression checklist for old payment methods; accessibility testingAccessibility testingChecking that people with disabilities can use the product, for example with a screen reader.Open in glossary → of the new button with a screen reader. Mention what is automated, if anything, so nobody duplicates it by hand.

Environments and the device/browser matrix

Where will you test? Usually a stagingStagingA pre-release environment that mirrors production as closely as possible.Open in glossary → environment with sandbox payment keys, never productionProductionThe live environment that real users use.Open in glossary → with real money. Then the device matrixDevice matrixThe list of devices and OS versions a team tests on, chosen to represent real users.Open in glossary → (or browser matrixBrowser matrixThe agreed list of browsers, versions and devices a site supports, and how deeply each is tested.Open in glossary → for websites): a short, deliberate list of devices, OS versions and browsers that represents your real users and your risks.

Device	Why it’s on the list
iPhone 16 · iOS 18 · Face ID	Main Apple Pay path
iPhone SE · iOS 17 · Touch ID	Oldest supported iOS, different authentication
Pixel 9 · Android 15	Main Google Pay path
Samsung Galaxy A · Android 13	Popular budget phone, oldest supported Android
Phone with no card in its wallet	“Wallet unavailable” path

Use your analytics to pick devices. “Every phone in the office” is not a matrix, it’s a pile.

Test data

List the accounts, cards, coupons and orders you need, and how you’ll get them. For wallets: Apple’s sandbox tester accounts with Apple’s test cards added to Wallet, and Google Pay’s TEST environment, which returns test tokens so no real card is charged. Ask for test data early: it’s the most common reason testing starts late.

Entry and exit criteria

Entry criteriaEntry and exit criteriaConditions that must be met before a test activity can start (entry) or before it counts as done (exit).Open in glossary → say when testing can start; exit criteria say when it’s done enough to give a recommendation.

“Zero bugs of any kind” sounds strict but is unrealistic, so it gets quietly ignored. Criteria that can’t be met teach the team to ignore criteria.

Risks and mitigations

This is the heart of risk-based testingRisk-based testingPrioritizing testing by risk: how likely something is to fail and how bad the impact would be.Open in glossary →: you spend the most effort where a failure is both likely and painful. For each risk, rate likelihood and impact from 1 to 3, multiply, and test the highest scores first and deepest.

Risk	L × I	Mitigation
Customer charged twice	2 × 3 = 6	Double-tap and slow-network cases; check PayCo dashboard
Wallet amount ≠ cart total	2 × 3 = 6	Cases with coupon, shipping, tax
Paid but no order created	1 × 3 = 3	Kill app / drop network after paying
Button style off in dark mode	2 × 1 = 2	One checklist item

Include project risks too, not just product risks: “Sandbox accounts not ready by Monday → testing starts late. Mitigation: request them today.”

Schedule and responsibilities

Who tests what, and when. Keep it to a few lines: “Ana: iOS. Ben: Android. Days 1 to 2 data and cases, days 3 to 7 execution, day 8 regression, day 9 summary.” Also name who makes the release decision. That’s usually the product owner, not the tester.

Not sure how many days to put in? Estimating Testing Effort shows how to build the number and its range.

Deliverables

What the team gets from testing: test cases linked to the user storyUser storyA short description of a feature from the user's point of view.Open in glossary →, bug reportsBug reportA clear written description of a bug so developers can reproduce and fix it.Open in glossary →, and a short test summary reportTest summary reportA report at the end of testing that summarizes what was tested, results, open bugs, risks and a recommendation.Open in glossary → with a recommendation at the end.

Tools

Name them in one line: where cases live (a test management tool or a spreadsheet), where bugs go (for example JiraJiraA popular tool for tracking bugs, user stories and tasks.Open in glossary →), and any helpers such as a proxy toolProxy toolA program that sits between the app and the server so you can watch and change network traffic.Open in glossary → to simulate network failures.

How to write it, step by step

Worked example: Apple Pay & Google Pay at checkout

Here’s a complete one-page plan for the ShopFast shopping app. Notice how short each section is.

A template you can copy

# Test plan: <feature> (<app> <version>, <sprint>)
Owner: <you> · Reviewed with: <dev>, <PO> · Version: 1

## Scope
In: <features, platforms>
Out: <what we deliberately don't test, and why>

## Objectives
<1-3 sentences: what "good" means for users and the business>

## Approach
<test types, what is scripted, exploratory sessions, regression, automation>

## Risks (testing order)
| Risk | Likelihood | Impact | Score | Mitigation |

## Environments & devices
<staging/sandbox, device or browser matrix and why>

## Test data
<accounts, cards, coupons, how to get them>

## Entry / exit criteria
Entry: <...>
Exit: <...>

## Schedule & people
<who, what, when; who decides on release>

## Deliverables & tools
<cases, bug reports, summary report; where they live>

Reviewing it with the team

A plan nobody else has read is just your opinion. Book 10 to 15 minutes with the developer and product owner and ask:

• “Is anything in out of scope actually something you expect to be tested?”
• “Do these risk scores match your gut? What worries you most?”
• “Is this device list enough for our users?”
• “If we hit the exit criteria, would you be comfortable releasing?”

Write down the answers, update the plan, bump the version and link it from the ticket. If the scope or dates change mid-sprint, update the plan again and say so in stand-up.

Common mistakes