How to Write a Test Plan: Template and Real Examples

A test plan without an out-of-scope section is a document that says 'yes' to everything by default: every stakeholder assumes their feature is covered, and the team never reaches a defined end point. A one-page plan that people actually read and reference during testing is worth more than a 20-page document filed away before sprint start. This guide covers the sections a test plan actually needs, with real examples for each rather than abstract placeholders, including scope, risk assessment, entry and exit criteria, and a complete mini plan for a small feature.

What a Test Plan Is (and Isn't)

Is:

A document that defines the scope, approach, and resources for testing a feature or release
Communication between QA, developers, and stakeholders
A reference during testing so everyone knows what was supposed to happen

Isn't:

A list of test cases (that's a different document)
A guarantee that no bugs will ship
Something that needs 40 pages

A one-page test plan for a small feature is completely appropriate. The goal is clarity, not length.

The Core Sections

1. Feature/System Under Test

What exactly are we testing? Be specific.

Vague:

Testing the checkout process

Specific:

Testing the checkout flow for registered users: cart → shipping address → payment (Stripe) → order confirmation. Excludes guest checkout (tested separately) and refunds (not yet implemented).

2. Objectives and Goals

What are we trying to achieve with this testing effort?

Example:

- Verify that registered users can complete purchases for physical products

- Ensure payment processing integrates correctly with Stripe in both success and decline scenarios

- Confirm order confirmation emails are sent within 2 minutes of purchase

- Validate that inventory is decremented correctly after purchase

3. Scope

In scope:

User registration and login
Adding items to cart
Applying discount codes
Checkout with credit card
Order confirmation page
Order confirmation email

Out of scope:

PayPal integration (Phase 2)
Guest checkout (separate feature)
Returns and refunds
Mobile app (separate test plan)

This is the most important section to write carefully. Scope creep in testing is as real as scope creep in development.

4. Test Approach

How will the testing be done?

Example:

| Type | Approach | Who |

|------|----------|-----|

| Smoke testing | Manual, before regression | QA team |

| Functional testing | Manual test cases | QA team |

| API testing | Automated with Playwright | QA automation |

| E2E regression | Automated with Playwright | QA automation |

| Performance | Load test with k6 | DevOps |

| Exploratory | 2-hour session per sprint | QA team |

5. Test Environment

Where will testing happen?

Environment: Staging (https://staging.myapp.com)
Data: Fresh staging DB seeded with test data
Browser: Chrome (primary), Firefox (regression)
Mobile: iOS Safari via BrowserStack (smoke only)

API credentials: Stripe test mode keys
Stripe test card: 4242 4242 4242 4242
Decline card: 4000 0000 0000 0002

6. Test Data

What data needs to exist before testing starts?

Users:

3 registered users with different roles (admin, member, viewer)
1 user with saved payment method
1 user with expired payment method
Edge case: user with very long name (for form truncation testing)

Products:

Standard product (in stock)
Out-of-stock product
Product with discount code applied
Digital product (no shipping required)

Discount codes:

SAVE10 — 10% off, active
SAVE50 — 50% off, active
EXPIRED99 — expired, should not apply

7. Risk Assessment

What are the riskiest areas? What could go wrong?

|------|-----------|--------|------------|

Higher risk = more test coverage needed.

8. Entry and Exit Criteria

Entry criteria (testing can start when):

All features in scope are deployed to staging
Smoke tests pass
Test data is set up
API documentation is up to date

Exit criteria (testing is done when):

All high-priority test cases pass
No open P1 or P2 bugs
Performance tests pass (< 2s page load)
Regression suite passes

9. Test Schedule

| Activity | Start | End | Who |

|----------|-------|-----|-----|

10. Defect Management

How will bugs be tracked?

Tool: Jira
Project: CHECKOUT
Priority labels: P1 (blocker), P2 (major), P3 (minor), P4 (cosmetic)

P1 blockers: Stop testing, fix immediately
P2 major: Fix before release
P3 minor: Fix in next sprint if possible
P4 cosmetic: Add to backlog

Bug report template:
- Environment
- Steps to reproduce (numbered)
- Expected result
- Actual result  
- Screenshot/video
- Browser/OS

11. Roles and Responsibilities

| Person | Role |

|--------|------|

| Anna Smith | QA Lead — overall plan, sign-off |

| Bob Jones | QA Engineer — test case writing, manual testing |

| Carol Wu | QA Automation — Playwright scripts |

| Dave Kim | Developer — bug fixes, technical questions |

| Eve Brown | Product Manager — requirements, acceptance criteria |

A Complete Mini Test Plan

Here's what a real test plan looks like for a small feature — user profile editing:

Test Plan: User Profile Edit Version 1.0 | Author: QA Team | Date: 2026-01-15 Feature: Users can edit their display name and avatar from their profile page. Scope:

In: Name change, avatar upload (JPEG/PNG, max 5MB), name validation
Out: Email change (requires email verification, separate plan), password change

Test Approach:

Manual functional testing of happy path and edge cases
API testing of the /api/users/{id} PUT endpoint
Automated regression for critical flows

Environments: Staging with seeded test accounts Test Data Needed:

User account with existing avatar
User account with no avatar
Test images: valid JPEG (2MB), valid PNG (4MB), oversized (10MB), invalid format (PDF)

Risks:

File upload size limit enforced client-side only — must test server-side too
Avatar storage (S3) — test what happens when upload fails

Exit Criteria: All P1/P2 bugs closed, name and avatar update correctly for all test cases, regression suite green

That's it. A good test plan can fit on one page.

Common Mistakes

Too vague: "We will test the login feature." Test how? All browsers? All user roles? API only? UI only? Too long: A 20-page document that nobody reads isn't useful. If stakeholders won't read it, it's not communicating anything. No scope section: Without explicit out-of-scope items, every stakeholder assumes their thing is covered. Missing risk assessment: You'll spend equal time on low-risk and high-risk areas instead of prioritizing. No exit criteria: How do you know when you're done? "When we run out of time" is not an exit criterion.

Summary

A test plan covers:

1. What's being tested (and what isn't)

2. How it will be tested (manual, automated, exploratory)

3. Where testing happens (environments)

4. What data is needed

5. What risks exist and how to mitigate them

6. When testing starts and ends (entry/exit criteria)

7. Who is responsible for what

Keep it short and specific. A one-page test plan that everyone reads is infinitely more valuable than a 20-page document that sits in a folder.