Download the test plan template and evidence register
The editable text file contains an original completed planning example and a blank form. The CSV contains six proposed cases with expected observations, owners, and empty fields for actual results and evidence. Both downloads are available without registration.
The example follows a client-intake release in the fictional SaaS BriefRelay. Its candidate RC-7, requirements, accounts, and cases are teaching material. Every case is marked Not run. The files describe a plan rather than results from a real application.
Start by replacing the decision, candidate identifier, scope, and requirements. Then review the proposed cases with the people who will execute and assess them. A reusable form saves setup work, but the release's actual risks determine which checks belong in it.
What is a test plan?
A test plan organizes verification for a bounded change or test cycle. It records objectives, included and excluded work, methods, environments, data, responsibilities, timing, and the conditions for starting and finishing. BrowserStack's QA guidance describes these as central planning decisions.
For a small SaaS team, the useful question is concrete: what must we observe about this candidate before the named owner can decide on a pilot? The answer can be a short plan linked to detailed cases and evidence. Length alone does not improve its usefulness.
Keep the plan connected to the acceptance criteria. A criterion describes observable behavior. A case describes an exercise and expected result. The plan coordinates the work, while an execution record states what actually happened.
Define the release and the decision
BriefRelay's fictional change lets a permitted client submit a brief, receive a reference, and retrieve its own receipt. Support needs to inspect status without opening private file contents. The plan supports a pilot decision for that bounded workflow.
Record an exact build or commit, configuration, schema, and relevant dependency versions. RC-7 is only an illustrative candidate label until the team connects it to an actual artifact. If the implementation changes, existing evidence may no longer describe the version being considered.
Write exclusions alongside inclusions. This example excludes payment processing, a new identity provider, unrestricted file types, and broad security certification. An excluded area remains unverified by this plan; it should not disappear into an implied claim that the whole product was tested.
| Record | Question it answers |
|---|---|
| Acceptance criterion | What observable behavior is required? |
| Test case | How will we exercise and assess it? |
| Test plan | How will the overall verification work run? |
| Execution evidence | What happened for this candidate and environment? |
| Release decision | What did the authorized owner decide given that evidence? |
Choose cases from requirements and risks
The example starts with four requirements: validate the required title, scope a receipt to its authorized workspace, preserve one logical submission across a retry, and provide a usable rejected-upload recovery path. Each becomes a proposed observation in the register.
Prioritize the consequential failures. A direct request for another workspace's receipt deserves attention even when the ordinary screen looks correct. A lost response and repeated submission exercise a different failure path from a single successful click.
Add the expected observation before execution. For the repeated submission, the plan expects one logical submission with a stable reference. A separate new request should still create its own authorized record. This distinguishes duplicate prevention from accidentally blocking legitimate work.
Use the risk register to explain why cases were selected. A simple count of cases does not reveal whether the important permission, recovery, and repetition paths were covered.
Prepare environments, data, and responsibilities
Use isolated Alpha and Beta workspaces, synthetic users, and invented files for this exercise. Record which principal belongs to which workspace and which resource belongs to each. Without that setup, a permission result can be difficult to interpret.
Prepare a valid brief, one missing its title, one deliberately unsupported file, a replay request, and an unrelated receipt identifier. Define a reset procedure so earlier attempts do not silently change the next case's starting state.
Assign execution and review separately when that helps. Engineering prepares the candidate and automation; Support exercises recovery; Product reviews expected behavior. The release owner still needs a clear decision record. Replace these illustrative roles with actual names or accountable teams.
Choose browser and device coverage from the product's use. A responsive intake path may need both mobile and desktop observations, keyboard operation, and relevant accessibility checks. Document the covered configurations instead of claiming every browser was tested.
Set entry, exit, and pause conditions
Entry conditions describe what must be ready: identified candidate, available environment, agreed expected behavior, prepared data, and permitted access. If the staging configuration is uncertain, resolve that before interpreting a test result.
Exit conditions state what evidence and unresolved findings the owner needs. In this example, all named cases must be executed against the candidate, permission failures must be addressed, and other failures need a recorded resolution or explicit release decision.
Keep blocked and Not run cases visible. A test blocked by an unavailable dependency has not passed. A defect fix needs its affected case rerun and the relevant regression work considered; editing a status field is not verification.
Pause if the environment identity becomes unclear, real customer data appears unexpectedly, or a failed boundary prevents reliable continuation. Record the reason and the conditions for resuming. The plan should help the team make the next decision, not pressure it to finish a checklist.
Record results that another person can assess
For each executed case, supply the candidate, actual result, status, evidence reference, owner, and any defect link. State the observation precisely: the server returned a denial without the unrelated receipt contents is more useful than security looks good.
Keep sensitive logs in their approved store and use references in the shared register. A screenshot can support an interface observation, but it may not establish the server state or an asynchronous worker's eventual outcome.
Review counts by status and their meaning. Six planned cases, four passed cases, one failed case, and one blocked case describe different facts. Do not convert that mixture into a single completion percentage that hides the unresolved work.
A feature-flag rollout can add controls around exposure and recovery. Those controls complement the plan; they do not turn missing verification into a passing result.
Use and maintain the plan after the first review
Record the release decision, decision owner, date, candidate, and remaining risks. Link the accepted evidence so a later support or engineering review can reconstruct what was considered. A passing case and an approved rollout remain separate records.
Revisit affected cases when upload behavior, workspace scoping, receipt creation, or environment assumptions change. Keep stable requirement and case IDs so changed behavior can be traced without rewriting every reference.
The resource files were checked for matching requirement IDs, consistent fictional labels, and explicit unexecuted statuses. No BriefRelay application was implemented or tested. Use usability testing for questions about how people understand and complete the workflow.
Sources and original exercise checked October 28, 2026. Begin with a small plan whose observations support a real decision, then expand it when the change and its consequences require more coverage.