How to Create a Test Plan: A Step-by-Step Guide With Examples

A new engineering manager joins a team mid-release and asks the QA lead a simple question: what exactly is being tested before this ships, and what isn't. The honest answer, on more teams than anyone likes to admit, lives in three people's heads and a half-finished spreadsheet nobody has opened since kickoff. Two weeks later an auditor asks a similar question about a compliance-sensitive feature. The same scramble happens again.

A test plan is supposed to prevent both scrambles. Written well, it is the one document that lets someone outside the QA team, a manager, an auditor, a new hire, understand what is being tested, what is deliberately out of scope, and why. This guide covers how to create a test plan as a living scope and risk document, not a box-ticking exercise you write once before "real" testing starts. You'll get a step-by-step process, a worked example, and a template to reuse.

What is a test plan, and how does it differ from a strategy or a test case

A test plan is a document scoped to one release, feature, or project. It states what will be tested, what will not, how it will be tested, who is doing it, and by when. It sits between two other documents people often confuse it with.

• A test strategy is broader and more permanent: the org's general policy on test levels, tools, and the split between manual and automated testing, written once and reused across many projects.
• A test case is narrower and more granular: a single documented scenario, its steps, and its expected result, one of possibly hundreds that a test plan's scope produces.

The test plan is the middle layer. It takes the strategy's general policy and applies it to one specific piece of work. Execution then happens as a set of individual test cases derived from that plan.

Many teams write a document they call a test plan that is actually trying to be both at once. It tries to set permanent policy and describe one release's scope in the same three paragraphs, and it satisfies neither job well. Separating the two documents, even informally, fixes most of the confusion.

Why a test plan matters beyond ticking a box

Teams that skip a real test plan usually don't skip testing. They skip the documentation of testing, and that gap shows up at the worst moment. Four things a good test plan buys you.

• Scope communication: a product manager can see at a glance that the new bulk export feature is tested for CSV output but explicitly not tested against files over 50,000 rows this release.
• Risk documentation: naming the highest risk areas up front, like a payment integration or a permissions change, means nobody discovers the risk was never planned for after a customer does.
• Stakeholder alignment: engineering, product, and support agree on entry and exit criteria before code freeze, not during a heated Slack thread the night before release.
• Audit trail: for regulated features, the plan is evidence that testing was scoped deliberately, which matters more than any individual test result on its own.

Consider the release held on a Thursday because a critical bug surfaced in the checkout flow. If the test plan had named payment processing as a high risk area needing extra coverage, that bug might have surfaced on Tuesday during planned testing. Instead it turned into a rushed pre-release scramble that pushed the release by three days.

The cost compounds over a year. A team that reworks its scope from scratch on every release, because nothing was written down last time, spends real hours re-deciding questions it already answered months ago. Multiply that by six releases a year and it adds up to days of wasted planning meetings that a saved template would have skipped entirely.

A step-by-step process for creating a test plan

Write the plan in this order. Each step builds on the last, and skipping one usually shows up as a gap later.

1. State the objective

One or two sentences: what is this plan testing and why does it exist right now. Example: "Verify the new saved payment methods feature works correctly across supported browsers before general release." A vague objective like "test the new feature" gives the rest of the plan nothing to anchor to.

2. Define scope, in and out

List what is covered and, just as importantly, what is not. "In scope: adding, editing, and deleting a saved card; selecting a saved card at checkout. Out of scope: recurring subscription billing, which ships in a later release."

Being explicit about what is out of scope matters as much as what's in. A support team that assumes recurring billing was tested, because the plan never said otherwise, will file the wrong kind of bug report when it breaks in production three weeks later.

3. Choose the test approach

Name the mix of manual and automated testing, which levels apply (unit, integration, end-to-end), and any specific techniques like exploratory sessions for the riskiest flows. Be concrete: "unit and integration tests cover the card storage API; a 45 minute exploratory session covers the checkout picker UI." Vague language like "thorough testing" tells the next reader nothing about what actually happened.

4. Plan resources and schedule

Who is testing, what environments and test data they need, and the dates testing starts and must finish by. A plan with no dates is a wish list, not a plan. Name real people and real days, not "the QA team" and "sometime before release."

5. Set entry and exit criteria

Entry criteria are conditions that must be true before testing starts, such as the feature being deployed to staging with seeded test data. Exit criteria are conditions for calling testing done, such as zero open critical bugs and 95% of planned test cases executed. Write both as things a third party could check without asking you.

6. Document risks

List what could go wrong and how the plan addresses it. A payment feature might list "third party gateway timeout" as a risk, with a mitigation of testing against a simulated slow response. Rank risks so the highest one gets tested first, not last, in case time runs short.

A worked example: saved payment methods feature

Here is a condensed real plan for the feature used above.

Objective: Verify saved payment methods work correctly across Chrome, Safari, and Firefox before general release.

Scope: In: add, edit, delete, and select a saved card at checkout. Out: recurring billing, corporate multi-card accounts.

Approach: Automated unit and integration tests for the card storage API. Manual exploratory testing for the checkout picker UI, focused on error states like expired or declined cards.

Resources and schedule: Two QA engineers, staging environment with three seeded test cards, testing runs Monday through Thursday of release week.

Entry criteria: Feature deployed to staging, test data seeded, no open blocker bugs from development.

Exit criteria: Zero open critical or high severity bugs, all planned test cases executed and recorded.

Risks: Third party payment gateway declines silently under load. Mitigation: add a specific test case simulating a gateway timeout.

Notice how short each field stays. A test plan that runs to ten pages usually means someone padded it to look thorough. A one page plan that a stakeholder actually reads is worth more than a five page plan that sits unopened in a shared drive.

A reusable test plan template

Copy this structure for your next feature or release.

• Objective: one to two sentences on what and why
• Scope in: bullet list of what is covered
• Scope out: bullet list of what is explicitly not covered
• Approach: mix of test levels and techniques
• Resources: who is testing, what environments and data
• Schedule: start date, end date, key milestones
• Entry criteria: conditions required before testing starts
• Exit criteria: conditions required to call testing complete
• Risks: what could go wrong and the mitigation for each

Fill in every field even when the answer is short. An empty "risks" section is a red flag that nobody actually thought about what could go wrong, not evidence that nothing could. Keep the whole document to one page if you can. A plan people actually read beats one that merely exists.

Keeping the plan alive instead of letting it go stale

The biggest failure mode isn't writing a bad plan. It's writing a good one and then never opening it again once execution starts. A test plan for a 900 test suite that takes 50 minutes to run is only useful if the exit criteria still reflect reality three weeks later, after scope shifted twice.

A test management tool helps here in a specific way. Instead of the plan living in a static document while execution happens somewhere else, the scope and risks defined in the plan stay linked to the actual test cases being written, run, and versioned.

When scope changes mid release, that change is visible next to the test cases it affects rather than buried in an edit history nobody checks. A tester picking up a case three weeks into a release can see the current scope and the current risk list without pinging the QA lead to ask if the plan is still accurate.

Tesbo isn't the only tool that can hold a plan this way. What matters is keeping the plan and the cases in the same place, so the plan doesn't quietly drift away from what the team is actually running. That link is what stops a test plan from becoming an artifact nobody trusts by week two of a six week release.

A plan reviewed and adjusted at the halfway point of a release, even briefly, catches most of the drift that would otherwise go unnoticed until exit criteria don't match reality anymore.