Skip to content
steelabs

Template

Focused test plan

Define the risks, scope, test data, ownership and completion criteria for a change before the first test run. Includes a small planning example.

Download editable Markdown

How to use this

Useful for: Teams aligning a testing effort with a specific release or feature.

  1. Start with the consequence of failure rather than a list of screens. A payment, permission change or data migration deserves different evidence from a cosmetic adjustment.

  2. Name included and excluded scenarios. Keep assumptions explicit so nobody interprets a successful narrow test run as approval of the whole product.

  3. Arrange accounts, data and environments before execution. Write down who can unblock a dependency and which configuration differences limit the conclusions.

  4. Agree what completion means with the release owner. A percentage of executed cases is not enough if a high-impact workflow is still blocked or its expected behaviour remains undecided.

Scope and limitations: Tailor this plan to the change and its risks. It is not a universal coverage model, a contract for a full penetration test or a statement of regulatory conformity.

Document preview

# Focused test plan

## Change and purpose
- Feature / candidate build:
- Business goal and acceptance criteria:
- Release decision this testing supports:
- Test owner / product decision owner:

## Risk inventory
| Failure scenario | Consequence | Priority | Proposed evidence | Owner |
| --- | --- | --- | --- | --- |
| Describe the failure, not just the screen | | | | |

## Scope boundaries
- Included journeys, roles and supported clients:
- Excluded areas and reasons:
- Assumptions requiring confirmation:
- Dependencies or integration partners:

## Execution arrangement
- Environment, configuration and build identity:
- Accounts and permissions:
- Data creation, cleanup and isolation:
- Manual, API and automated checks to execute:
- Accessibility or specialist security review required:
- Evidence storage and sensitive-data handling:

## Completion and reporting
- Entry conditions before execution starts:
- Required checks and evidence before a decision:
- How blocked scenarios and defects are reported:
- Who accepts residual risk and until when:
- Summary owner and delivery date:
- Retest triggers after fixes or configuration changes:

## Planning example — fictional
Change: an organisation administrator can invite a new member.
Highest-impact risks: inviting into the wrong organisation; an ordinary member gaining invitation privileges; accepting an expired invitation.
Proposed checks: a successful invite using isolated test data; cross-organisation and role-boundary API requests; expired and already-used invitation links.
Excluded: billing and unrelated profile editing. Their exclusion must be agreed rather than inferred from a missing test case.
Entry condition: the candidate build is deployed to staging and test email delivery is available.
Completion condition: the invitation scenarios have recorded results, privileged access checks are reviewed, and open defects have a release-owner decision.

Revise the plan when the feature scope changes. Keep a link to the eventual test summary so the intended coverage can be compared with what actually ran.

Read alongside this worksheet

Get help applying itAll resources