This test plan template helps you decide what to test, what must be ready first, and what evidence the review will need. The filled example plans a small browser workflow. It contains no executed tests or release approval.
Name the build and the work in scope
The original fictional system is an equipment-loan request preview. A visitor chooses an item and enters a quantity from one through five. Build LP-0.4 is the proposed test target. The page should reject invalid fields, build a preview for valid fields, and clear an old preview when an input changes.
| Plan field | Filled teaching example |
|---|---|
| Objective | Check the request-to-preview behavior for the supplied catalog and quantity rules. |
| In scope | Item selection, quantity validation, preview contents, stale-preview clearing, keyboard use, and narrow-layout readability. |
| Out of scope | Inventory reservation, payments, email delivery, staff approval, and live borrowing. None is represented by the preview. |
| Target | LP-0.4 with fixture set F2; record the actual served build and fixture identity when execution occurs. |
| People | Test coordinator plans and records the cycle; data reviewer confirms F2; product reviewer reviews outcomes and exceptions. These are fictional roles. |
Atlassian's test-plan guidance brings together scope, approach, resources, environment, cases, risks, and success/reporting criteria. Use those sections to settle the work before running it. A template does not supply the decisions for your actual product.
Connect the risks to the planned scenarios
The example's catalog fixture F2 proposes B01 · Binoculars and T01 · Tripod. The data reviewer has not yet confirmed that this is the correct catalog for LP-0.4.
| Case | Risk and supplied input | Expected behavior to inspect |
|---|---|---|
| TP1 | Wrong preview contents: B01, quantity 2. | Preview names Binoculars and quantity 2. |
| TP2 | Empty quantity accepted: B01, blank quantity. | Identify the missing quantity and withhold the preview. |
| TP3 | Out-of-range quantity accepted: T01, quantity 6. | Explain the allowed range 1–5 and withhold the preview. |
| TP4 | An old preview misrepresents edited inputs: build B01/2, then change quantity to 3. | Clear the earlier preview until the visitor builds a new one. |
Select TP4 in the example to inspect its sequence beside the stale-output risk. Its setup needs a valid preview before the edit. A note saying only “change quantity” would leave that important starting state unspecified.
The test approach is manual execution in an isolated test environment at 720px and 360px, including keyboard operation. Record the actual browser and version when testing. These widths are example targets, not a claim that every supported device or browser is covered.
Check readiness before starting
The proposed entry conditions are: identify the served LP-0.4 build, obtain the data reviewer's confirmation of F2, make the isolated environment available, and have the four cases and recording fields ready.
In the supplied planning snapshot, F2 confirmation is pending. The cycle therefore remains waiting for the data review. Select Entry review to see that dependency, its owner, and the next question: “Does F2 match the catalog intended for LP-0.4?” The page should not turn a pending review into a failed software test.
Schedule execution after those conditions are met, then reserve time for issue review and any retesting. Actual dates and participant availability must come from the team. If the target build or fixture changes, review which cases and expected behaviors need updating before continuing.
Define what the cycle must report
For this example, the proposed exit review requires an actual result and evidence reference for every in-scope case, a reviewed disposition for each issue, and retest evidence or an explicitly recorded exception where relevant. The product reviewer decides how unresolved issues affect the next step through the team's real process.
This rule does not promise that executing four cases makes the product ready to release. It makes the bounded cycle reviewable. Record exclusions and untested areas alongside the results so a reader can see the limits.
Use separate fields for case/version, build, environment, actual input, expected behavior, observed behavior, result, evidence, and issue reference. Leave actual-result fields empty until execution. An expected result copied into the Observed field is not test evidence.
Copy a prompt for the plan and review page
Create one complete HTML software test-plan review page.
Product/build and bounded objective: [PASTE]
In-scope risks/features and explicit exclusions: [PASTE]
Approach, environment, browsers/viewports and data fixtures: [PASTE]
Owners, dependencies, entry/exit rules and schedule: [PASTE]
Planned cases, expected behavior and reporting fields: [PASTE]
Use supplied facts; do not invent runs, pass rates or release approval.
Include this separate original fictional planning example:
Equipment-loan request preview, target LP-0.4, fixture F2.
Items: B01 Binoculars; T01 Tripod. Quantity: integer 1–5.
Scope: item/quantity validation, preview contents, stale-preview
clearing, keyboard use and readability at 720px/360px.
Exclude inventory reservation, payments, email, staff approval
and live borrowing. Manual isolated-environment approach.
Fictional roles: test coordinator; data reviewer; product reviewer.
F2 is a proposed fixture awaiting the data reviewer's confirmation.
TP1: B01/2 must preview Binoculars and quantity 2.
TP2: B01/blank must name missing quantity and withhold preview.
TP3: T01/6 must explain 1–5 and withhold preview.
TP4: build B01/2, edit quantity to 3; clear old preview until rebuilt.
Show each case's risk, setup/input/sequence and expected behavior.
All actual results are unexecuted and remain blank.
Entry: exact served LP-0.4 identity, confirmed F2, isolated
environment and four cases/recording fields ready. Supplied state:
F2 confirmation pending, so cycle waits for data review, not test fail.
Entry review must show the blocking condition, owner and question:
Does F2 match the catalog intended for LP-0.4?
Exit proposal: every scoped case has actual result/evidence;
each issue has reviewed disposition and retest evidence or explicit
recorded exception where relevant. No automatic release decision.
Schedule execution after readiness; actual dates not supplied.
Provide Scope, case selection and Entry review controls. They
inspect the plan; they do not execute cases or approve data.
Keep expected vs observed fields separate. Include a blank plan
scaffold and local review-notes area; preserve typing across views
and ask before reset. No test runner, deployment or pass dashboard.
Use at least 16px text, labeled native controls, visible focus and
stacked records at 360px without overflow. Inline CSS/JavaScript,
no external assets, network or storage. State notes are temporary
in this open page. Return complete HTML and unresolved plan decisions.
Read the generated plan with the people supplying the environment and data. Confirm that TP4 preserves its initial state, F2's review remains a prerequisite, and the reporting section separates intended behavior from an actual observation.
Put the readiness decision in front of the reviewers
An HTML review copy can show scope, scenarios, and entry conditions together. Put it in your NOS workspace when the data reviewer and test coordinator need to inspect that arrangement.
If “Data ready” obscures the actual condition, clarify the static wording to “F2 confirmed for LP-0.4 by the data reviewer” in visual editing mode. Save the correction so colleagues can reopen the existing link and read it. Obtain and record the actual confirmation in the maintained test plan; editing its description does not provide it.
Start execution when the agreed conditions are met, and keep the resulting observations and evidence in the team's test records. Use the plan's scope and exit questions to explain what that cycle established.