Guide

What Is a Test Plan? How to Write One (With a Template) in 2026

A test plan locks in what you'll test, who's responsible, and what 'done' means, before the work starts. What goes in one, and how to write one that doesn't go stale.

Dhaval Shreyas

CEO & Co-founder at Pie

11 min read Posted Jul 10, 2026

What Is a Test Plan?

A test plan is a document that defines the scope, approach, resources, and schedule for testing a piece of software. It states what will be tested and what won’t, how the testing will be done, who is responsible, what environments and data are required, and what criteria decide whether the software passes. It is the agreed answer to “what does ‘tested’ mean for this release?” written down before the work begins.

The international glossary maintained by ISTQB defines a test plan as “documentation describing the test objectives to be achieved and the means and the schedule for achieving them, organized to coordinate testing activities.” The key word is coordinate. A test plan’s job isn’t to list every keystroke. It’s to align everyone who depends on the testing effort (developers, QA, product, operations) on the same definition of scope and success.

A useful test plan does three things. It makes scope explicit, so nobody assumes a feature is covered when it isn’t. It surfaces risk early, so the team spends its limited testing time where failure would hurt most. And it sets exit criteria, so “are we done testing?” has an answer that isn’t just “we ran out of time.” Everything else in the document supports those three outcomes.

Test Plan vs Test Strategy vs Test Case

A test plan, a test strategy, and a test case are three different artifacts at three different altitudes, and conflating them is the most common source of confusion in test documentation. A test strategy is the high-level, often organization-wide policy, the general approach, standards, and tools that apply across many projects. A test plan applies that strategy to one specific release or project. A test case is a single executable check with concrete steps, inputs, and an expected result.

The relationship is hierarchical. One test strategy informs many test plans. One test plan governs hundreds or thousands of test cases. The strategy says “we automate regression at the API and UI layers and we test on the two most common devices.” The plan says “for the v4.2 checkout release, here is the in-scope set, the schedule, the owners, and the exit criteria.” Each test case says “given an expired card, the payment screen shows error E-203.”

Mixing the levels is what produces documents nobody trusts, putting per-case steps in the strategy, or leaving scope undefined in the plan.

What Goes Into a Test Plan?

A standard test plan contains scope, approach, criteria, resources, schedule, and risk, organized into named sections. The reference structure comes from IEEE 829, the IEEE Standard for Software and System Test Documentation, which was folded into and superseded by ISO/IEC/IEEE 29119-3, the current international standard for test documentation. Almost no team follows either standard to the letter, but they define the vocabulary nearly every template borrows.

The sections that consistently earn their place:

• Features to be tested, and not tested. State both. An explicit out-of-scope list prevents the costliest misread in testing: assuming a flow was covered when it never was.
• Test approach. Manual, automated, the levels and types involved.
• Entry and exit criteria. What gates when testing starts and stops.
• Pass/fail criteria. The bar for individual items.
• Test environment and data. What’s required to run the plan.
• Roles and responsibilities. Who owns what.
• Schedule and milestones. When each piece lands.
• Deliverables. What the effort produces.
• Risk and contingency. What could go wrong and the fallback.

The risk section is where a good plan earns its keep. A bug caught in production costs far more to fix than the same bug caught before merge, so the plan decides, deliberately, where to aim limited testing time. Get this section right and the defects that slip are the cheap ones, not the ones that page you at 2 a.m.

The trap is treating every section as mandatory boilerplate. A plan padded with sections the team will never read is a plan the team will never read. The discipline is to keep the sections that change a decision, scope, risk, and exit criteria above all, and ruthlessly trim the ceremony around them.

What Are the Types of Test Plans?

Test plans come in three broad types, distinguished by their scope: master test plans, level-specific test plans, and type-specific test plans. The terminology again traces to IEEE 829 and ISO/IEC/IEEE 29119, and choosing the right type is mostly a question of how much you’re coordinating.

1. Master test plan. Sits at the top and coordinates testing across multiple levels or teams. On a large project it defines how unit, integration, system, and acceptance testing relate, who owns each, and how results roll up to a release decision.

2. Level-specific (or phase) test plan. Covers a single level, such as a system test plan or an acceptance test plan, with the detail the master plan delegates.

3. Type-specific test plan. Focuses on one kind of testing where the approach is distinctive enough to warrant its own document, such as a performance, security, or regression testing plan.

In practice, the type you need scales with team size and risk. A two-person product team rarely needs a master plan and a sheaf of level-specific plans; a single living page covering scope, risk, and exit criteria does the job. A regulated enterprise shipping across many teams genuinely benefits from the master-plus-level structure, because the coordination cost is real and the plan is how it’s paid.

How to Write a Test Plan (Step by Step)

Writing a test plan is a sequence of decisions, not a fill-in-the-blanks exercise, and the decisions matter far more than the formatting. The goal is a document short enough that people read it and specific enough that it settles arguments. Here is a practical order of operations.

1. Define the scope, including what’s out. List the features, flows, and platforms in scope, then explicitly list what is not being tested this cycle. The exclusions prevent the most expensive misunderstanding in testing: someone assuming a flow was covered when it never was.

2. Identify the risks first. Before deciding how to test, decide what would hurt most if it broke: payments, auth, data loss, the core flow your revenue depends on. Risk-based prioritization is how a finite testing budget gets aimed at the right targets instead of spread evenly across things that don’t matter equally.

3. Choose the approach per area. Decide which areas are manual, which are automated, and at which levels. Map high-risk, high-change flows to automated regression coverage and reserve manual effort for exploratory and one-off checks. This is also where you name tools and frameworks.

4. Set entry and exit criteria. Entry criteria define when testing can begin (build deployed, environment ready, test data seeded). Exit criteria define when it’s done (all critical cases pass, no open blockers, coverage thresholds met). Without exit criteria, “done” silently becomes “out of time.”

5. Nail down environment and data. Specify the environments, devices, and test data needed, and who provisions them. Industry research from Capgemini and Sogeti’s annual quality report has repeatedly ranked test data quality among the top priorities holding back automation progress. A plan that hand-waves this section is a plan that stalls on day one.

6. Assign owners and a schedule. Name who is responsible for each area and when each milestone lands. Vague ownership (“QA will test it”) is how things fall between people. A name and a date make the plan executable.

7. Keep it alive. A test plan is a forecast, and forecasts go stale. Review it when scope changes, and treat the document as something you maintain through the release, not something you sign and shelve.

A Test Plan Template You Can Copy

A good template gives you the sections without the bloat, so you can fill in decisions instead of inventing structure. The skeleton below distills the IEEE 829 / ISO/IEC/IEEE 29119-3 sections down to the ones that change how a team works. Drop the sections that don’t apply to your effort rather than padding them out.

Why the Static Test Plan Breaks Down

A test plan captures decisions: what’s in scope, where the risk sits, what release-ready means for this product. That judgment is the durable part, and no tool should take it from you. What breaks is everything downstream of it, the execution the plan assumes is happening.

It Was Built for a Slower Cadence

A plan written for a quarterly release made sense when releases were quarterly. Ship several times a day and a document that lists every test case and gets signed off once is obsolete before the ink dries. It becomes a fiction the team maintains for compliance instead of a tool it uses for quality. The judgment in the plan still matters. The frozen inventory of cases stapled to it does not.

The Real Gap Is Between Planning Coverage and Having It

A plan can specify, in beautiful detail, that every critical flow has automated end-to-end coverage. Then reality erodes it:

• The UI changes and selectors break.
• A script fails, and someone silences it to unblock the release.
• Real coverage quietly diverges from what the plan claims.

The document says the flows are covered. The suite says otherwise. That drift is the same maintenance tax that makes teams under-build the end-to-end layer in the first place, the layer that catches the bugs users actually hit.

Keep the Judgment Human. Automate the Upkeep.

Pie doesn’t replace your plan. It executes the coverage the plan calls for, so the artifact and the engine stop drifting apart.

• You own the judgment. Scope, risk, and the definition of done stay human decisions in the plan.
• Pie owns the execution. It discovers the flows in your app and drives them the way a user would, locating elements by what they look like and do.
• Coverage stays current on its own. Pie self-heals through routine UI changes, so no one rewrites tests every sprint just to keep the plan honest.

The plan still says what matters and why. Autonomous QA keeps the day-to-day coverage behind it from going stale.

Plan the Coverage, Then Keep It Alive

A test plan is worth writing because it forces three decisions before a release: what’s in scope, where the risk is, and what “done” means. Keep those sharp and you’ve captured most of a plan’s value, whether the artifact is a 20-page enterprise document or a single living page in your wiki. The format is negotiable. The clarity is not.

What changes in 2026 is the labor behind the plan, not the plan itself. Your judgment about scope and risk is still yours. The hand-maintained suite that’s supposed to enforce it is the thing that quietly falls out of date.

We built Pie because we were tired of plans that told a story the test suite couldn’t back up. Write the plan to decide what matters. Let Pie keep the coverage behind it honest, sprint after sprint, without anyone babysitting a selector.

Dhaval Shreyas

CEO & Co-founder at Pie

13 years building mobile infrastructure at Square, Facebook, and Instacart. Now building the QA platform he wished existed the whole time. LinkedIn →