What is a Test Plan? 12 Components with IEEE 829 Template (2026)

Last updated: July 11, 2026 · 10 min read

A test plan is the QA blueprint for a release. It answers: what will we test, how, when, by whom, and what could go wrong. This guide covers the classic IEEE 829 components, a lean modern template, and how test plans work in agile teams.

A test plan is a formal document describing the scope, approach, resources, and schedule of testing activities for a release, project, or product. It's typically owned by the Test Lead and reviewed by dev leads, PMs, and stakeholders before execution starts.

See also our STLC guide — the test plan is the deliverable of the Test Planning phase.

1. Test plan identifier — unique ID and version.
2. Introduction — purpose, scope, references.
3. Test items — modules, features, and versions under test.
4. Features to be tested — explicit list with priorities.
5. Features NOT to be tested — and why.
6. Approach — testing types (functional, performance, security), automation strategy, tools.
7. Pass/fail criteria — what counts as a passing item.
8. Suspension & resumption criteria — when to halt or restart testing.
9. Test deliverables — cases, scripts, reports, defect logs.
10. Environment needs — hardware, OS, browsers, test data, integrations.
11. Responsibilities & staffing — who does what and when.
12. Schedule & risks — milestones, dependencies, mitigations.

# Test Plan — <Feature/Release>

## 1. Scope
What's in / what's out.

## 2. Approach
Manual + automated. Tools: Playwright, k6, Postman.

## 3. Test types
- Functional  - Regression  - Performance  - Security

## 4. Entry / Exit criteria
Entry: build in QA env, smoke passes.
Exit: 100% P1/P2 tests executed, 0 open S1/S2, sign-off from PM.

## 5. Environment
Staging URL, seeded data set, feature flag list.

## 6. Deliverables
- Test cases in TestRail  - Automated suite in GitHub Actions  - Test summary report

## 7. Roles
- Test Lead: X  - QAs: Y, Z  - Dev on-call: A

## 8. Schedule
Sprint 24 → freeze Wed, regression Thu, sign-off Fri.

## 9. Risks
- Third-party payment sandbox flakiness → have manual fallback

• Author — Test Lead or senior QA.
• Reviewers — Dev Lead, Product Manager, DevOps.
• Approver — QA Manager and/or Product Manager.

Agile teams don't write 40-page test plans per sprint. Instead they maintain:

• A single evergreen test strategy at the product level.
• A one-page test approach per epic.
• An acceptance-criteria checklist per user story — this is the sprint-level test plan.

See Agile Testing Methodology for more.

• Writing a test plan no one reads. Aim for one page per epic.
• Skipping the "NOT to be tested" section — stakeholders assume everything is covered.
• Confusing test strategy (long-lived, product-level) with test plan (release-specific).
• Ignoring environment risks — the #1 cause of blown release dates.
• Not defining exit criteria — the release drags on forever.

• What is STLC?
• Defect Life Cycle
• Agile Testing Methodology

The 12 IEEE 829 fields still matter for regulated releases, but 90% of SaaS teams need a lean, one-page plan they can rewrite per epic in 20 minutes. This is the exact template we hand to new QA leads at SoftwareTestPilot — every section is 1–3 lines because anything longer stops being read.

# Test Plan — Checkout v2.0 (Epic PROJ-4820)

## Scope (in / out)
IN:  New Stripe Payment Intents flow · SAVE10 coupon logic · 3DS challenge redirect
OUT: PayPal, Apple Pay, marketing pop-up on /cart (owned by Growth)

## Entry criteria
- Build 24.7.x deployed to qa-checkout.stpilot.dev
- Smoke suite green on last commit
- Feature flag `checkout_v2` enabled for QA tenant

## Exit criteria
- 100% P1 + P2 cases executed; ≥ 95% pass rate
- 0 open S1/S2 defects; ≤ 3 open S3
- PM sign-off recorded in ticket

## Approach
API-first: Postman collection PROJ-CHECKOUT-v2 covers 34 endpoints.
UI regression: 12 Playwright specs, run in parallel on GitHub Actions.
Exploratory: 2 x 90-min sessions targeting 3DS + coupon edge cases.

## Environments & data
Staging URL, seeded via /scripts/seed-checkout.ts
Test cards: 4242 (success), 4000 0025 0000 3155 (3DS), 4000 0000 0000 0002 (decline)

## Deliverables
TestRail run R-2411 · Allure report artifact · release-notes.md defect summary

## Roles
Test Lead: Priyanka · QAs: Rohan, Sara · Dev on-call: Karthik · PM: Alex

## Schedule
Sprint 24 · Freeze Wed 15:00 IST · Regression Thu · Sign-off Fri 12:00 IST

## Top risks & mitigation
1. Stripe sandbox flake → manual fallback with 5 recorded cURL calls
2. 3DS redirect on WebKit is flaky in CI → run WebKit locally, tag @flaky
3. Coupon SQL query regression (PROJ-4211 history) → add contract test

How to run it as a 3-amigos artifact

In agile, the plan should be walked through in the first sprint ceremony (3-amigos or backlog refinement) with the PM and lead engineer in the room. Two minutes per section, no slides. The value is the shared mental model, not the doc; if the PM cannot restate the exit criteria back to you, the plan is not done.

What to link out to instead of duplicating

• Test cases → TestRail run URL (never copy IDs into the plan).
• Environment config → the IaC repo commit, not a screenshot.
• Historical risk data → the epic's defect life cycle dashboard, filtered by component.
• Automation coverage → the Allure trend line, not a static number.

A plan that links to living data ages well; a plan that copies data goes stale in one sprint.

Original SoftwareTestPilot research relevant to manual QA:

• Login-page test coverage benchmarks (2026) — which coverage areas ship real production defects.
• Test pyramid benchmarks (2026) — real ratios vs the Cohn model.
• Shift-left benchmarks (2026) — defect cost by lifecycle stage.
• QA salary benchmarks (2026) and QA jobs hiring now.