What a test plan includes
Nine sections cover what, how, who and when. Here’s what goes in each, with an example.
ScopeWhat will and won’t be tested.
ObjectivesWhat the testing must prove.
Test approachTypes of testing and how they run.
Test environmentDevices, browsers, data and accounts.
Entry and exit criteriaWhen testing starts, and when it’s done.
ScheduleDates for each testing phase.
Roles and responsibilitiesWho does what.
Risks and mitigationWhat could go wrong, and the plan B.
DeliverablesWhat you’ll hand over.
Test plan example: login and checkout release
A complete one-page plan for a two-week release.
How to write a test plan in 5 steps
Scope first, schedule last.
- Define the scopeList what’s in and out, so nobody assumes something is tested when it isn’t.
- Choose the approachPick the test types and levels: functional, regression, API, performance, and who runs them.
- Plan the environment and dataName the devices, browsers, test accounts and data you need, and when they’ll be ready.
- Set entry and exit criteriaAgree when testing can start and what ‘done’ means, for example no open high-severity bugs.
- Assign roles and the schedulePut names and dates against each phase, then share the plan for review and sign-off.
Test plan vs test strategy
A strategy sets the overall approach. A plan applies it to one project or release.
Answers: how do we test, in general?
Test strategy
The organisation’s or product’s overall approach: test levels, types, tools and standards. It changes rarely.
Example: ‘Every release gets automated regression in CI and a manual exploratory session.’Answers: how do we test this release?
Test plan
Scope, schedule, environment, people and criteria for one specific project or release.
Example: Login and checkout release: 3 days of execution on staging, sign-off by the QA lead.
Stay in the loop
Get new batch dates on WhatsApp. One message when a batch opens, nothing else.
By subscribing you agree to receive WhatsApp messages from Tester Academy. Read our Privacy policy.