Test Plan Template: A Light Version for Small Teams

A test plan says what will be tested for a feature or release, how, where, by whom, and what has to be true before you call testing finished. For a small team it fits on one page with eight headings: scope, out of scope, approach, environments and data, entry criteria, exit criteria, risks, and owners. Below is a template to copy, a filled example for a checkout feature, and a guide to how much plan a change actually needs.

The ISTQB glossary defines a test plan↗ (opens in a new tab) as “documentation that describes test objectives, means and schedule for achieving test coordination.” The key word is coordination. A plan is not the tests themselves; it is the agreement around them, so the developer, the tester and the person who signs off the release are working to the same list. The individual scripted checks are test cases, and they have their own test case template.

Where the formal versions come from

Most test plan templates online descend from IEEE 829, the standard for software test documentation. IEEE now lists IEEE 829-2008↗ (opens in a new tab) as a superseded standard, replaced by the ISO/IEC/IEEE 29119 series.

The current part on documents is ISO/IEC/IEEE 29119-3:2021↗ (opens in a new tab), which “specifies software test documentation templates that can be used for any organization, project or testing activity.”

Those templates are thorough because they serve regulated and contracted work, where the plan is evidence. A team of five shipping a web app every week does not need every section. It needs the decisions those sections force: what is in, what is out, how you will know you are done, and what worries you. The light template keeps those and drops the rest.

What goes in a light test plan

• Scope. The features, stories or tasks under test, by name or ref. If it is not listed, it is not covered.
• Out of scope. What you are deliberately not testing this time, and why. This line prevents more arguments than any other.
• Approach. Which kinds of testing, at which level: unit and integration tests in CI, manual exploratory sessions, a regression pass, accessibility checks. Say what is automated and what a person does.
• Environments and data. Where tests run (staging, a preview build, which browsers and devices), which test accounts, and which test data, such as payment test cards.
• Entry criteria. ISTQB defines entry criteria↗ (opens in a new tab) as “the set of conditions for officially starting a defined task.” For testing: the build is deployed, unit tests are green, the test data exists.
• Exit criteria. The matching definition for exit criteria↗ (opens in a new tab) is “the set of conditions for officially completing a defined task.” For testing: every in-scope case run, no open bugs above an agreed priority, known issues written down and accepted.
• Risks. What could go wrong and what you will do about it: the riskiest areas get the most testing, and anything you cannot test gets a named fallback.
• Owners. One name per job: who tests, who fixes, who decides the exit criteria are met. A plan where everyone owns sign-off has no sign-off.

Many templates add a schedule. Add one if your release has a fixed date; leave it out if testing simply runs until the exit criteria are met.

The test plan template

TEST PLAN: <feature or release name>
Version / date:  <v1, October 1, 2026>
Author:          <name>

1. Scope
   In:   <features, stories or task refs under test>
   Out:  <what is not tested this time, and why>

2. Approach
   Automated:  <unit, integration, end-to-end; where they run>
   Manual:     <exploratory sessions, regression pass, accessibility>
   Cases:      <where the test cases live; how many, roughly>

3. Environments and data
   Where:      <staging URL or build; browsers and devices>
   Accounts:   <test accounts and their roles>
   Data:       <seed data, payment test cards, sample files>

4. Entry criteria (testing starts when)
   - <build deployed to staging>
   - <unit and integration tests green>
   - <test data and accounts ready>

5. Exit criteria (testing is done when)
   - <all in-scope cases run>
   - <no open bugs at priority N or more urgent>
   - <known issues listed and accepted by: name>

6. Risks
   - <risk> -> <what we do about it>

7. Owners
   Testing:    <name>
   Fixes:      <name>
   Sign-off:   <name>

A filled example: saved cards at checkout

Here is the template filled for one feature on a US web store: letting signed-in customers save a card and reuse it at checkout. It took fifteen minutes to write, and it surfaced two questions (gift cards and the ZIP code check) before anyone started testing.

TEST PLAN: Saved payment methods at checkout
Version / date:  v1, October 1, 2026
Author:          Dana (QA)

1. Scope
   In:   FET-212 Save a card at checkout
         FET-213 Pay with a saved card
         FET-214 Remove a saved card from Account > Payments
   Out:  Gift cards (unchanged this release)
         Mobile app (ships next release; separate plan)

2. Approach
   Automated:  Unit tests for card tokenization and default-card
               logic; API integration tests in CI; one end-to-end
               test: sign in, add to cart, pay with saved card.
   Manual:     60-minute exploratory session on checkout;
               keyboard-only pass on the payment form;
               regression pass on guest checkout.
   Cases:      Test case sheet, tab "Saved cards", 24 cases.

3. Environments and data
   Where:      staging.example.com, build 2026.10.1
               Chrome, Safari, Firefox (desktop); Safari on iPhone;
               Chrome on Android
   Accounts:   tester01@example.com (no saved cards)
               tester02@example.com (two saved cards)
   Data:       Payment provider test cards only; success, decline
               and expired cards; billing ZIP codes 10001 and 94105

4. Entry criteria
   - Build 2026.10.1 on staging
   - CI green on the release branch
   - Payment provider sandbox keys set on staging

5. Exit criteria
   - All 24 cases run; none Blocked
   - No open bugs at priority 1-3
   - Guest checkout regression pass complete
   - Known issues listed and accepted by Sam (product)

6. Risks
   - Card data handled by our servers -> confirm only provider
     tokens are stored; check logs for card numbers
   - Saved card used with a new billing ZIP code -> add cases;
     question to product: should the ZIP check re-run?
   - Payment sandbox slow in the afternoon -> run payment cases
     in the morning

7. Owners
   Testing:    Dana
   Fixes:      Lee (web)
   Sign-off:   Sam

Entry and exit criteria examples

Entry and exit criteria are the two sections teams most often leave vague, so here are lines to borrow. Pick the ones you will actually enforce; a criterion nobody checks is decoration.

• Entry, any test run: the build under test is named and deployed; the environment matches the plan; test accounts can sign in.
• Entry, manual testing: developers have run the feature once themselves; known gaps are listed in the task before handover.
• Entry, a release regression pass: every feature in the release has met its own exit criteria; the release branch is frozen except for fixes.
• Exit, a feature: every in-scope case has been run; every failure is filed as a bug; no open bug at the agreed priority or above.
• Exit, accessibility: keyboard-only and screen reader passes done on every changed page, and any failures filed with the criterion they break.
• Exit, a release: the regression pass is complete; open bugs below the bar are listed in the release notes or accepted by name; the person who signs off has said yes in writing.

Writing each section well

• Name things by ref. “FET-212” cannot be misread; “the card stuff” can.
• Make exit criteria countable. “Quality is acceptable” cannot be checked; “no open bugs at priority 1-3” can.
• Put the risky parts first. ISTQB calls this risk-based testing↗ (opens in a new tab): choosing and prioritizing test activities by risk. Money, sign-in, permissions and data loss usually top the list.
• Write out-of-scope items as decisions, with who made them. “Mobile not tested” reads as an oversight; “Mobile ships next release; separate plan (Sam)” reads as a choice.
• Use test data you are allowed to use. Example addresses, provider test cards, never real customer records.
• Keep it short enough to reread. If nobody opens the plan after the kickoff, it was too long or in the wrong place.

How much test plan a change needs

• A small bug fix: no separate document. Three lines in the task are the plan: what was tested, where, and the regression you checked.
• A feature: one page, like the example above.
• A release with several features: one page per feature, plus a release-level plan for the regression pass and the go/no-go call. What to re-run is in the regression testing checklist.
• Regulated or contracted work: use the full ISO/IEC/IEEE 29119-3 structure, or whatever your contract or auditor names. The light template is a starting point, not a substitute.

Drafting a test plan with an AI assistant

An AI assistant is useful for the first draft, especially for the risks and out-of-scope lists people leave thin. Give it the requirements and the template, and ask it to list questions rather than invent answers:

Draft a test plan for the feature below using the template below.

- Scope: list only what the requirements describe, by ref.
- Out of scope: suggest items and mark each one "to confirm".
- Risks: at least five, the riskiest first, each with a response.
- Exit criteria: countable conditions only.
- Use example.com accounts and payment test cards, never real data.
- Where the requirements do not say, list the question instead of
  guessing.

Requirements:
<paste>

Template:
<paste>

Then check it the way you would check a colleague’s draft: is every in-scope item really in the requirements, are the exit criteria ones your team will actually hold to, and does each risk have an owner? The questions list is often the most valuable part; each one is a gap in the requirements.

Keeping the plan next to the work

A test plan in a shared folder goes stale the day testing starts. On a fenbs board, every task has a note for the problem, a separate plan for how it will be done, and a Testing section for how it was checked: Tested, Partly tested, Failed, or Needs owner check for what only a person can confirm, with notes on what was run and what was not. For a single feature, the test approach can live in the task’s plan and the result in its Testing section, so the plan and the outcome sit together. Bugs found during the run become tasks of kind bug, with a priority from 1 to 10, which is what an exit criterion like “no open bugs at priority 1-3” is counted against.

Exit criteria that hold for every release, such as “no release with an open priority 1 bug”, belong on the Decisions and rules page, recorded as decided by a person, where every connected AI assistant reads them first. What fenbs does not do: it has no due dates, so a release schedule lives in your calendar, and no settable assignee, so owners are named in the plan text. It does not store or run test cases either; keep those in a spreadsheet or a test tool.