What a test plan is for
A test plan answers five questions for the people who fund and depend on testing: what will be tested, what will not, how, by whom, and when will we know we are done. Everything else is supporting detail. If a section does not help a reader answer one of those questions, cut it. The plan is also the place where you record the test strategy decisions that apply to this specific release: which test levels run, which product risks drive the depth of testing, and which criteria stop or resume execution.
Plans fail review for two reasons. Either the approach is vague (a paragraph that says we will test thoroughly) or the criteria are missing, so nobody can tell later whether the plan was met. The steps below force both into the open.
The ten sections and what goes in each
| Section | What goes in it | Typical length |
|---|---|---|
| 1. Identifier and scope | Plan name, version, product and release it covers, the one-paragraph statement of what is in scope | 3 to 6 lines |
| 2. References | Requirements baseline, design documents, the master test strategy, the risk register, the release plan | A bullet list |
| 3. Test items | The builds, services, configurations and data sets under test, with version identifiers | A table, 5 to 15 rows |
| 4. Features to be tested | Each feature or requirement group with its risk class and the test levels that cover it | A table, one row per feature |
| 5. Features not to be tested | What is excluded and why: out of scope, covered elsewhere, accepted risk | 3 to 8 lines |
| 6. Approach | Test levels, test types, techniques per risk class, automation stance, regression policy, tooling categories | Half a page to two pages |
| 7. Pass and fail criteria | Requirement coverage target, pass rate, open defect limits by severity, non-functional thresholds | 5 to 10 measurable lines |
| 8. Suspension and resumption | The conditions under which execution stops (blocking defect, environment down) and what must be true to restart | 4 to 6 lines |
| 9. Deliverables, environment, staffing | Reports and logs produced, environments and data needed, roles, named people, training gaps | Half a page |
| 10. Schedule and risks | Milestones with dates, dependencies, project risks to the testing itself with a contingency for each | A table plus 5 to 10 risk rows |
Write the plan in seven steps
Fix the scope before anything else
Write the one-paragraph scope statement and the features-not-tested list first. Ninety percent of plan arguments are scope arguments, and it is cheaper to have them on day one than after the schedule is drawn.
Pull the product risks in
Copy the risk register, or run a one-hour risk-based testing session, so each feature carries a likelihood and impact score. The score decides how deep you test, which is the substance of the approach section.
Choose levels, types and techniques per risk class
For each risk class write one line: which test levels cover it, which test types apply, which design techniques you will use. High risk gets boundary analysis, state models and exploratory sessions; low risk gets a smoke check and a sampled regression.
Write measurable criteria
Turn every criterion into a number: 100 percent of high-risk requirements covered, zero open severity 1 defects, at most 5 open severity 2 defects with workarounds, 95 percent pass rate on the final regression run. A criterion you cannot check on the last day is not a criterion.
Estimate and schedule
Size the work with one of the test estimation techniques, then place the milestones against the release plan. Show the dependencies on builds and environments explicitly; they are where schedules slip.
List the project risks and their contingencies
Late builds, an environment that is shared with another team, a single tester who knows the payment gateway. For each, one sentence of contingency. Reviewers trust a plan that admits what could go wrong.
Review twice, then baseline
Send the draft to development, product and operations for a 48-hour written review, resolve comments, then hold a 30-minute walkthrough. Baseline the version that leaves the walkthrough and change it only through the change log.
One page or ten pages
The right length depends on who reads the plan and what they need it for. A single team delivering a sprint to a product owner they see daily needs one page: scope, risks, criteria, and who does what. A release that goes through a change board, an external audit, or a customer acceptance gate needs the full ten sections, because those readers were not in the room and will not accept a verbal answer.
- One page when the team is stable, the product owner attends planning, the release cycle is under a month, and no external party signs off.
- Three to four pages when several teams integrate, or when operations and support need the environment and schedule detail.
- Ten pages when a regulator, auditor or paying customer will read it, or when the release carries safety, financial or legal consequences.
- Never pad a plan to look thorough. Reviewers read the criteria and the schedule and skim the rest.
Worked example: a payment feature
Suppose the release adds card payments with a saved-card option to an existing web shop. The scope statement covers card capture, authorization, saved-card reuse and refunds through the new gateway; it excludes the existing wallet flow, which is covered by the standing regression suite. The risk session scores card capture at likelihood 4, impact 5 (20, high), refunds at 3 and 5 (15, high), saved-card reuse at 3 and 4 (12, medium), and the receipt email at 2 and 2 (4, low).
The approach then writes itself. High-risk items get boundary analysis on amounts and card numbers, a state model for the authorization lifecycle, security checks against the OWASP guidance for payment data, and two 90-minute exploratory sessions each. The medium item gets equivalence partitioning and one exploratory session. The low item gets a single functional check. Pass criteria: all high and medium requirements covered, zero open severity 1 or 2 defects, refund reconciliation matching the gateway report to the cent across 200 sampled transactions. Suspension: any defect that corrupts stored card tokens stops execution until a fix is verified in the integration environment. The whole plan fits on three pages and takes about ten hours to write and review.
If you cannot state the pass criteria in five measurable lines, you do not yet have a plan; you have an intention. Write the criteria first and the rest of the document falls into place.
Mistakes reviewers catch
- An approach section that names tools instead of techniques. Reviewers want to know how you will find defects, not which product you bought.
- Criteria without numbers, such as testing will be complete when quality is acceptable.
- A schedule with no dependency on build delivery dates, which makes the test dates fiction.
- Missing suspension criteria, so a broken environment turns into a week of arguments about whether testing counts.
- No features-not-tested list, which means every omission becomes a surprise at release time. See the glossary for the exact meaning of terms like test item and test basis when you fill in the template.
Common questions
What is the difference between a test plan and a test strategy?
The strategy is the standing, organization-level statement of how testing is done: levels, types, entry and exit rules, automation stance. The plan applies the strategy to one release or project with specific features, dates, people and criteria. One strategy, many plans.
Is IEEE 829 still current?
IEEE 829 was superseded by ISO/IEC/IEEE 29119-3 in 2013, but its section structure is still what most reviewers expect and it maps directly onto the newer standard. Using the ten sections above satisfies both.
How long should a test plan take to write?
A release-level plan takes 8 to 16 hours for the first draft plus two review cycles of about two hours each. A one-page sprint plan takes under an hour once the strategy exists.
Do agile teams need a test plan?
They need the content, not necessarily the document. A one-page plan or a planning section in the sprint wiki that states scope, risks, approach and done criteria is a test plan. Skipping the content, rather than the format, is what causes trouble.
Who signs off a test plan?
The test lead owns it; development lead, product owner and, where relevant, operations and the customer representative approve it. Sign-off means they accept the scope and the criteria, not that they promise the dates will hold.
How often should the plan change?
Whenever scope, risk scores or criteria change, through a logged revision. A plan that never changes after baseline is usually one that nobody reads.
Sources
- IEEE 829-2008, Standard for Software and System Test Documentation (IEEE Standards Association)
- ISO/IEC/IEEE 29119-3:2021, Software testing, Part 3: Test documentation
- ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus and overview
Further reading named in the text
- Rex Black, Managing the Testing Process, 3rd edition (Wiley, 2009)
- Cem Kaner, James Bach, Bret Pettichord, Lessons Learned in Software Testing (Wiley, 2002)
This guide is part of the test management hub. It is best read alongside test strategy and risk based testing, which cover the neighbouring questions.