Test Plan Template

Download test plan template (Markdown)

A test plan is a dated document for one release, one project, or one change. It says what will be tested, what will not, who does the work, which environments are in play, and what “done” means.

It is not a test strategy. Strategy lasts across releases. The plan is the instance: this checkout rewrite, this iOS build, this model upgrade.

Download the Markdown outline, or copy the sections below into Confluence, Google Docs, or your tracker.

When you need a written test plan

Write one when more than one person must agree on scope before testers start. Typical triggers:

• A named release with a date
• A change that cuts across teams (payments, permissions, data migration)
• External testers joining for a cycle (QA outsourcing or a dedicated QA team)
• A stakeholder who will ask “what did you actually test?”

Skip a formal plan when one engineer is checking a one-line fix and the risk is already named in the ticket. A template is not a ritual.

Test plan vs test strategy vs test cases

Artefact	Question it answers	Lifespan
Test strategy	How we test this product in general	Until the product shape changes
Test plan	What we will test in this release	One release or project
Test cases	Exact steps and expected results	Until the behaviour changes
RTM	Which requirements have cases	Updated every scope change

If you find yourself pasting the company mission into a test plan, you are writing a strategy (or a brochure). Cut it.

Sections of a useful test plan

Older IEEE 829 outlines are longer than most product teams will maintain. Use the ten sections in the download. If a section has nothing to say, write “None” and move on. An empty heading is better than a paragraph of filler.

1. Purpose

One paragraph. Name the product and the change. “Confirm that the new sign-in service behaves as specified on web and iOS before 22 August” is a purpose. “Ensure world-class quality” is not.

2. Scope

In scope and out of scope, as lists. Out of scope is the valuable half. If performance, accessibility, or AI testing is not in this plan, say so. Otherwise people will assume it was.

3. Test items

The builds, APIs, or features under test. Include version or commit if you have one. “The website” is not a test item.

4. Approach

How you will test, not a history of QA. Example: structured cases on critical journeys, exploratory time on the new UI, automation only where last cycle’s cases already exist, no load test in this plan.

5. Entry and exit criteria

Entry: build installed, test data ready, known blockers listed. Exit: planned cases executed or waived, High defects resolved or accepted, RTM updated. Suspension: environment down, blocking defect, missing data.

Do not set exit to “zero bugs.” You will either lie or never ship.

6. Environments and test data

Name the environment (staging, a named sandbox) and the data you need (roles, payment states, expired tokens). If you cannot get production-like data, that is a risk, not a footnote.

7. Schedule and roles

Who writes cases, who executes, who signs off, and the window. If Nexus Eclipse is executing, this is where the engagement sits against your sprint — see managed testing or QA as a service if the plan is recurring rather than one release.

8. Risks

Only risks that change how you test: late build, no iOS device, third-party sandbox reset, model provider rate limits. Each row needs a mitigation, even if the mitigation is “accept and watch.”

9. Deliverables

Point at the living files: matrix, cases, execution log, bug reports, summary. Do not promise a 40-page PDF unless someone asked for one.

10. Approvals

Names and dates. A plan nobody signed is still useful as a working note; do not pretend it was approved.

Blank test plan (copy)

Product: Release / version: Author / date: Status: Draft | Review | Approved

1. Purpose
2. Scope (in / out)
3. Test items
4. Approach
5. Entry, exit, suspension
6. Environments and data
7. Schedule and roles
8. Risks
9. Deliverables
10. Approvals

The downloadable Markdown file is this outline with tables already in place.

Short worked example

Purpose. Confirm the new email-and-password sign-in service on web (Chrome, Safari) and the iOS app before the 22 August release.

In scope. Sign-in, lockout after five failures, password reset, session timeout, error-message wording that must not reveal whether an email is registered.

Out of scope. SSO, performance, accessibility audit, Android (follows in the next plan).

Approach. Cases from the RTM for High requirements; two 90-minute exploratory sessions on the new error states; no new automation in this cycle.

Entry. Staging build 2026.08.19, test users provisioned, email sandbox working.

Exit. All High RTM rows Covered or waived in writing; no open Blocker or Critical on in-scope items.

Risk. Email sandbox drops messages — mitigation: a second mailbox provider and a manual token path for reset tests.

That is a complete small plan. It is shorter than this article on purpose.

Entry, exit, and waivers in practice

Write criteria as checks, not moods.

Entry examples that work

• Named build installed on the named environment
• Test accounts for each in-scope role exist and can sign in
• Payment or email sandbox is reachable
• Known production defects that will also appear in staging are listed so they are not re-logged as new

Exit examples that work

• Every High RTM row is Covered, Partial-with-waiver, or Out of scope
• No open Blocker or Critical on in-scope items, unless a named person accepted it
• Execution log points at the build that was actually tested
• Open Major defects are listed in the release note, not hidden in a chat thread

A waiver is a written decision to ship with a gap. It needs the requirement ID, the risk, who accepted it, and whether it is deferred to a dated follow-up. “We ran out of time” is a reason; it is not a waiver until someone owns the leftover risk.

If you cannot get entry criteria, do not start a full cycle and then invent coverage. Say the plan is blocked. That is more honest than a green summary of tests you could not run.

After the plan: the test summary

The plan says what you intended. The summary says what happened. Keep it short:

• Build tested
• Cases planned / run / blocked
• High RTM gaps still open
• Defects still open, by severity
• Waivers

Do not paste every passed case. Point at the log. The people who read a summary want residual risk, not a transcript.

Agile: living plan vs one-off document

In a two-week sprint, the plan can be a page in the release ticket. The same headings still help. What fails is a 15-page plan written once in January and ignored.

Update the plan when:

• Scope is cut or added
• The environment changes
• A blocker kills a whole area (then record the waiver)

Do not rewrite the plan every day. Change the RTM and cases daily; change the plan when the agreement changes.

What not to put in a test plan

• Marketing language about the company
• A full case list (link it)
• Invented pass percentages as a target
• Tool tutorials
• A second copy of the strategy

If a section is copied from the last six releases unchanged, it belongs in the strategy, not here.

Related templates

• Requirements traceability matrix
• Test case template
• Test strategy document
• Bug report template

We write these plans as part of functional testing and QA consulting. The template is free; filling it against a live product is the work.

FAQs

What is a test plan template?

A reusable outline for a release-specific testing agreement: scope, approach, criteria, environments, risks, and owners.

How long should a test plan be?

Long enough that a tester who was not in the meeting can execute without guessing scope. For most product releases that is a few pages, not a booklet.

Do we need a test plan if we already have user stories?

Stories are inputs. A plan is the testing agreement across those stories: what is in, what is out, and what “done” means for the set.

Is this the same as a test strategy document?

No. Strategy is how you test the product over time. The plan is one release. Keep them separate or you will update neither.

Can this work for AI features?

Yes. Name the model-backed surfaces in scope, say whether evaluation sets exist, and treat a prompt or model change as a new test item. Detail lives under AI Quality.

Will you write the plan for our release?

Yes, on an engagement. Contact us with the product URL and the release date.