What Should Be Included in a Software Test Plan?

A software test plan should cover scope and what is explicitly out of scope, the test levels and types you will run, environments and test data, entry and exit criteria, roles, schedule, deliverables, defect handling and risks. Everything else is optional. The two sections that settle arguments later are the out-of-scope list and the exit criteria.

This is written for engineers and QA leads producing a plan for a real release rather than for an auditor. It covers what belongs in each section, the process for writing one, how much detail your team actually needs, and what the document does once testing has started.

What should be included in a software test plan?

A software test plan should include the sections below, and a plan missing any of the first six will generate an argument at some point in the cycle. The wording of each section matters less than whether someone had to make a decision to write it.

Section	What it settles	What happens without it
Scope	Which features, versions, platforms and integrations are under test	Three people test the same happy path and nobody opens the admin views
Out of scope	What is deliberately not being tested this cycle, and why	Every gap found after release is treated as an oversight
Test levels and types	Unit, integration, system and acceptance, plus performance, security and accessibility	Non-functional testing is discovered in the final week
Environments and test data	Which environment, which build, what data, who can reset it	A third of the failures turn out to be environment drift
Entry criteria	What must be true before testing starts	QA burns two days on a build that does not deploy
Exit criteria	What must be true before the release ships	The go or no-go call becomes a meeting about how everyone feels
Roles and owners	Named people for execution, triage and the release decision	Triage stalls because nobody is allowed to set severity
Schedule and milestones	Test windows, code freeze, the regression run, build dependencies	Testing absorbs whatever time development overran by
Defect management	Severity and priority definitions, triage cadence, escalation path	The same severity argument, per bug, daily
Risks and mitigations	What could stop testing, and the response	The one shared test device nobody booked

Add deliverables (where the cases live, what the summary report contains) and an approval line naming who can change the plan mid-cycle. Both are cheap to write and useful when the schedule slips.

Of that list, exit criteria are the section teams most often fudge. “No open critical or high defects, all P1 test cases passed, performance within 10 percent of the current release” is a criterion. “Testing complete” is a hope. Exit criteria written after the bugs start arriving are not criteria, they are negotiations. If your acceptance criteria are already specific at the story level, most of this work is done, and well-written acceptance criteria give you the pass conditions for free.

What is the purpose of a test plan document?

The purpose of a test plan is to get agreement, before testing starts, on what will be tested, by whom, in which environment, and what result permits the release to ship. It is a decision record more than a procedure.

The document does three jobs, in descending order of value:

1. It forces the argument early. Writing “out of scope: Safari on iOS 15, single sign-on flows” makes someone object in week one instead of in the release call. Almost all of the plan’s value is generated during its review.
2. It is a reference during execution. People go back to the environment details, the severity definitions and the exit criteria, repeatedly.
3. It is evidence afterwards. When a customer asks what was tested, or a postmortem asks how a defect escaped, the plan says what was in scope and what was not.

Nobody reads a test plan cover to cover after the first week. Judge yours by which sections people go back and look up, and cut the ones they never do. A plan that no one disagreed with during review is usually a plan no one read.

What are the steps of test planning?

Test planning runs from understanding the change, through deciding coverage and criteria, to arranging environments and getting the thing reviewed. There is no canonical five steps: templates in circulation count anywhere between four and nine, and anyone who insists on a specific number is counting their own template. The sequence below is the one most of them contain.

1. Read the requirements and mark the ambiguity. List what can be tested and, more usefully, the statements that cannot be tested as written. “Fast” and “handles load” are defects in the requirement, not in the code.
2. Decide levels and types. Which layers get automated coverage, what needs manual exploratory time, and which non-functional checks apply. Say plainly which ones do not.
3. Set entry and exit criteria in numbers. Write the build conditions that let testing start and the defect and coverage thresholds that let the release go out.
4. Plan environments and data. Name the environment, the deploy mechanism, the data set, its refresh process and the person who owns it. This is where most schedules quietly break.
5. Estimate and schedule against the build plan. Tie test windows to build availability, not to calendar dates invented in isolation. Include the regression run and the time to retest fixes, which is the estimate teams always omit.
6. Name owners and the escalation path. One person for execution, one for triage, one who makes the release call. Roles, not a team name.
7. Review it with the people who will be blamed. Engineering, product and whoever runs the deploy. Then fix a rule for changing the plan once testing is underway.

Step seven is the one worth protecting. The plan gets its value from engineers pushing back on the out-of-scope list and product disputing the exit criteria while there is still time to move something. Where that conversation happens matters less than whether it happens before sign-off: some teams run a 30-minute call, others do it in a thread. Projan is built for the second, putting the scope and exit-criteria questions to QA and engineering in Slack, keeping the answers attached to the plan, and exporting the follow-up tasks to Jira or Linear. The mechanism is interchangeable. Skipping the review is not.

How detailed should a test plan be?

A test plan should be as detailed as the cost of being wrong, which for most product teams is a page or two rather than a document. Detail costs maintenance, and a plan that goes stale in week two is worse than a short one that stays true.

Three rough tiers:

• Routine change to an existing product. Half a page in the ticket: what changed, the regression surface it touches, the environment, the exit condition. No document.
• New feature, new integration surface, or a release several teams touch. Two to four pages covering the full section list above. This is the standard case, and it is closely related to planning QA for a single feature before code ships.
• Regulated, safety-critical or contractually specified work. The full documented set, reviewed and signed, because here the plan is evidence and its format may be dictated by a standard or a customer.

What to leave out at every tier: your organisation’s testing policy, a tutorial on the test tooling, a glossary, a restatement of the requirements, and the full list of test cases. Link to where the cases live instead. Pasting them in guarantees the plan is wrong within a sprint.

Does an agile team still need a test plan?

Yes, but a much smaller one, and not per sprint. The parts that survive on an agile team are the ones that are still contested: exit criteria for the release, environment and data ownership, non-functional coverage, and who makes the go or no-go call. The rest is either in the tickets or in a standing team convention.

The practical form is one short page per release train or per epic, kept next to the work rather than in a documents folder, updated when the scope changes. If your team keeps a broader standing document about how testing is done in general, that is a different artefact with a different owner, and the distinction is worth getting straight: see test plan vs test strategy vs QA plan and who writes each.

Frequently asked questions

What are the 5 steps to create a test plan? There is no agreed set of five. Templates count anywhere from four steps to nine, and the numbering is a feature of the template rather than the discipline. If you want a compressed version: understand what is being built, decide what you will test and what you will not, fix entry and exit criteria, arrange environments and people, then get it reviewed by the engineers involved.

Which details are usually documented in a test plan? The details people look up later are the ones worth documenting: the exact build and environment under test, how to reset the test data, severity and priority definitions, the numeric exit criteria, and who makes the go or no-go call. Narrative sections about testing philosophy are written once and never opened again.

What is the difference between a test plan and a test case? A test plan describes the whole testing effort for a release: scope, environments, criteria, owners and schedule. A test case describes one specific check, with steps, input data and an expected result. A plan references where the cases live. Pasting hundreds of cases into the plan makes it unreadable and immediately stale.

Do you need a test plan for a small bug fix release? Not a full one. A patch release needs three things written down: what changed, what regression surface that change touches, and what result lets it ship. That fits in the ticket. The trap is a fix that looks small and sits under shared code, where the honest regression scope is much larger than the diff.

What is IEEE 829 and is it still used? IEEE 829 was the standard for software and system test documentation, last revised in 2008 and since superseded by ISO/IEC/IEEE 29119-3. Very few teams follow it directly now, but most test plan templates in circulation still carry its section list, which is why so many of them look identical. Treat it as ancestry, not obligation.

A test plan earns its place by settling the two questions that otherwise get settled under deadline pressure: what you are not testing, and what result lets the release ship. Write those two sections properly, keep the rest short enough to stay accurate, and put the draft in front of the engineers who will be asked why a defect escaped.