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:

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

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

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.

→ See also: Risk-Based Testing: Prioritizing What to Test When You Can't Test Everything | How to Write a Test Case: Format, Examples, and Common Mistakes | Test Case Design Techniques: EP, BVA, Decision Tables, State Transition