How to Write a Test Plan

What a test plan is for

A plan answers the questions stakeholders ask before and during testing: what exactly are we testing, what are we deliberately not testing, when will we know enough to release, what do you need from us, and what could stop you. If those answers exist only in the QA lead’s head, the plan does not exist, whatever the document says.

The classic outline comes from IEEE 829, whose test plan sections (test items, features to be tested and not to be tested, approach, pass/fail criteria, suspension and resumption, deliverables, environment, responsibilities, schedule, risks, approvals) are still recognisable in most templates. IEEE 829-2008 has since been superseded by the ISO/IEC/IEEE 29119 series; its part 3, ISO/IEC/IEEE 29119-3, is now the international reference for test documentation and treats the test strategy chosen for a project as part of the test plan. The ISTQB CTFL v4.0 syllabus describes the typical content of a test plan in similar terms: the context of testing, assumptions and constraints, stakeholders, communication, a risk register, the test approach, and budget and schedule.

The plan is a living document. It is written before test design starts, reviewed with development, product and operations, approved, and then updated whenever scope, dates or risks change — with a version number so everyone knows which one they are reading.

What a test plan contains

• Scope — the release or project, the test items (builds, services, apps, versions) and the boundaries of the system under test.
• Test objectives — what this round of testing must find or demonstrate, for example "no Critical defect in payments" or "every acceptance criterion of release 4.0 verified".
• Features to be tested — listed by requirement or story ID with a risk level, so the depth of testing per feature is visible.
• Features not to be tested — with the reason (unchanged, out of release, owned and tested by a vendor). This section prevents the most expensive misunderstandings.
• Approach — test levels and types, design techniques per feature, what is automated and where it runs, regression scope, non-functional testing, and any deviation from the strategy with its justification.
• Entry, exit, suspension and resumption criteria — see the next section.
• Environments — which environments, versions, integrations and sandboxes, devices and browsers, and who provides access.
• Test data — where it comes from (synthetic, generated), volumes, how it is reset, and privacy constraints.
• Schedule and milestones — test activities with dates and their dependencies on development, design and operations milestones.
• Resources, roles and responsibilities — who designs, executes, automates, triages, reports and signs off; allocation and any training needed.
• Risks and mitigations — project risks to the testing itself (late builds, unstable environments, missing skills), each with an owner. Product risks belong to the risk analysis that sets test depth.
• Assumptions and dependencies — what the plan takes as given and what testing needs from other teams, by when.
• Deliverables — test cases, automated tests, status reports, defect reports, the test completion report.
• Approvals — who approves the plan and, separately, who takes the release decision.

Try it: Requirements → Test Cases Try it: AI Test Coverage Analyzer

Entry, exit, suspension and resumption criteria

Criteria turn arguments into checks. Entry criteria define when a test activity may start; exit criteria define when it may be considered complete. Suspension criteria define when testing should pause because continuing would waste effort, and resumption criteria define what must be fixed before it restarts. The end-to-end quality assurance guide explains how entry and exit criteria act as release gates; the plan’s job is to make them specific and measurable for its scope.

• Entry — build deployed to the test environment, smoke suite green, acceptance criteria reviewed, test data loaded, required integrations reachable.
• Exit — planned tests executed (for example all High-risk tests and at least a stated percentage of the rest), no open Blocker or Critical defects, remaining defects accepted by the product owner, regression suite green, non-functional targets met.
• Suspension — smoke test fails on a new build, a key environment or sandbox is unavailable for longer than an agreed time, or a single defect blocks a large share of the planned tests.
• Resumption — a fixed build passes the smoke test, the environment is restored, or the blocking defect is verified as fixed.
• Write every criterion so that two people would reach the same yes/no answer; "sufficiently tested" is not a criterion.

Prioritisation, schedule and resources

Order the test work by risk first: the features with the highest likelihood and impact of failure are designed and executed first, so that if time runs out, what is left untested is the least dangerous. Within that order, respect dependencies — a feature cannot be tested before its build and data exist — and prefer early testing of anything that could force redesign, such as integrations with payment or identity providers. Coverage-based and requirements-based ordering are useful secondary rules.

Build the schedule backwards from the release decision. Leave explicit time for defect fixing and re-testing, for the final regression run, and for non-functional tests that need a stable build. Resource planning is more than headcount: record who has the domain knowledge, device access and automation skills each activity needs, and what happens when that person is unavailable. The effort figures themselves come from the estimate, which the test estimation guide covers.

• Schedule the riskiest and most dependency-heavy testing first, not the easiest.
• Plan at least one fix-and-retest cycle; plans without one assume there will be no defects.
• Keep a named backup for every critical skill: payments domain, mobile devices, performance tooling.
• Tie milestones to events, not only dates: "cycle 1 starts when entry criteria are met", with the target date alongside.

Try it: Risk-Based Test Generator Try it: AI Risk-Based Test Generator

A test plan template

Copy the outline below and delete what your context does not need. A section that stays empty should say why ("No performance testing: no server-side change in this release") rather than disappear, because the absence is a decision.

TEST PLAN - <product> <release or project>        ID: TP-<nnn>   Version: <x.y>
Status: Draft | In review | Approved     Owner: <QA lead>      Date: <yyyy-mm-dd>
Strategy reference: <link to test strategy and its version>

1.  Introduction and context
    Purpose, release summary, links to requirements, designs and the risk register
2.  Scope
    2.1 Test items                builds, services, apps, platforms and versions under test
    2.2 Features to be tested     <ID> <feature> - risk level - depth of testing
    2.3 Features not to be tested <feature> - reason
3.  Test objectives               what this round of testing must find or show
4.  Approach
    Levels and types; design techniques per feature; automation (what runs where);
    regression scope; non-functional testing; deviations from the strategy and why
5.  Criteria
    5.1 Entry   5.2 Exit   5.3 Suspension   5.4 Resumption
6.  Test environments             environments, versions, sandboxes, devices, browsers, access
7.  Test data                     sources (synthetic), volumes, reset procedure, privacy rules
8.  Schedule and milestones       activities, target dates, dependencies
9.  Resources and responsibilities  roles, people, allocation, backups, training needs
10. Estimates                     effort ranges and the assumptions behind them
11. Risks and mitigations         project risk - likelihood/impact - mitigation - owner
12. Assumptions and constraints
13. Dependencies                  what testing needs from whom, by when
14. Deliverables                  test cases, automated tests, status reports,
                                  defect reports, test completion report
15. Communication and reporting   cadence, channel, audience, escalation path
16. Approvals                     name - role - decision - date

Try it: Test Plan Generator Try it: AI QA Checklist Generator

A lightweight test plan for agile teams

In Scrum and similar frameworks the long-lived decisions sit in the strategy and the Definition of Done, and much of the plan lives in the backlog: each story carries its acceptance criteria and the team plans testing tasks in sprint planning. What is still worth writing down per sprint or release is short: the goal, what is in and out, the top risks and how they are tested, what regression runs, what the environment and data depend on, and any additions to the Definition of Done. One page, kept in the team wiki and linked from the sprint board, is enough.

SPRINT TEST PLAN - Bustan Market, sprint 42 (fictional)      one page, team wiki

Goal:      Customers can pay with Apple Pay on iOS and web; saved-card flow unchanged
In scope:  BUS-812 Apple Pay (iOS app, Safari), BUS-815 order confirmation email (ar/en)
Out:       Android wallet payments (planned for sprint 44), seller portal
Top risks: R1 payment captured but order not created (L4 x I5)
              -> idempotency and retry tests at API level, automated in CI
           R2 Arabic email totals misaligned (L3 x I3) -> RTL rendering check
Approach:  API tests for the new payment endpoint; one exploratory session per story;
           regression = automated checkout suite + manual saved-card check on 2 devices
Env/data:  staging + payment provider sandbox; synthetic customers only
DoD adds:  acceptance criteria pass; 0 open Blocker/Critical; regression green; demo done
Who:       Sara (QA, iOS), Omar (QA, web/API); developers own unit and API tests
If blocked: sandbox outage -> use mocked gateway responses; raise in daily stand-up

Worked example: an excerpt from a release test plan

For example, the excerpt below comes from a plan for release 4.0 of Bustan Market, the fictional Saudi marketplace used in the test strategy guide. It shows the sections people most often leave vague: features with risk and depth, features not tested with reasons, measurable criteria, a schedule with a fix-and-retest cycle, and project risks with owners.

TEST PLAN TP-040 - Bustan Market 4.0 "One-page checkout" (fictional excerpt)  v1.1

2.2 Features to be tested                                   Risk    Depth
    CHK-01 One-page checkout, web + apps (ar/en)            High    boundaries, negative,
                                                                    exploratory, auto regression
    CHK-02 Coupon and promotion stacking rules              High    decision table (14 rules),
                                                                    automated API tests
    CHK-03 Cash-on-delivery limit (max 2,000 SAR)           Medium  1,999.99 / 2,000.00 / 2,000.01
    CHK-04 Delivery slot picker (Hijri/Gregorian display)   Medium  both calendars, ar/en, RTL
    CHK-05 Order confirmation SMS and email                 Low     content check ar/en, one pass

2.3 Features not to be tested
    Seller portal - unchanged in 4.0; covered by the nightly regression suite only
    Courier tracking internals - partner-owned; our webhook handling IS in scope

5.  Criteria
    Entry:   4.0.0-rc deployed to staging; smoke green; acceptance criteria reviewed;
             payment sandbox reachable; synthetic data set v7 loaded
    Exit:    all High-risk tests executed and passed (or waived in writing by the PO);
             >= 95% of all planned tests executed; 0 open Blocker/Critical;
             <= 3 open Major defects, each with a fix date; regression green two nights
             running; p95 checkout API < 800 ms at 3x normal peak
    Suspend: smoke fails on a new build; sandbox down > 4 working hours;
             > 30% of planned tests blocked by one defect
    Resume:  fixed build passes smoke; sandbox restored; blocking defect verified

8.  Schedule (working days)
    D1-D3   design + data setup        D4-D11  execution, cycle 1 (High risk first)
    D12-D13 fix verification + full regression    D14 load test    D15 go/no-go

11. Project risks                         Mitigation                          Owner
    Payment sandbox instability           mocked gateway for negative paths   QA lead
    Late delivery of CHK-02 promotions    API-level tests first, UI last      Dev lead
    One tester on leave D8-D10            developer pairs on regression runs  Eng. manager

Try it: Regression Scenario Generator

Common test plan mistakes

• A plan that restates the strategy and says nothing about this release.
• No "features not to be tested" section — then everyone assumes their feature is covered.
• Exit criteria that cannot be measured ("adequate coverage", "stable build").
• No time for fixing and re-testing, or a schedule that ends on the release date with no buffer for the go/no-go decision.
• Mixing product risks (what could fail for users) with project risks (what could stop testing) in one undifferentiated list.
• Written once for approval and never updated; by mid-release it describes a different project.
• Approvals from people who never read it — review the scope, criteria and risks with them in a meeting instead.

Frequently asked questions

References

• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021The test process model: organisational, test management and dynamic test processes, with their activities and outcomes.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.