Skip to content
steelabs

Template

Exploratory testing charter

Give an exploratory session a mission, a time box and a reviewable record. Includes an example for an invitation workflow.

Download editable Markdown

How to use this

Useful for: Testers investigating a new feature or a risk that scripted checks do not describe well.

  1. Choose one investigation objective and the risk behind it. A charter should leave room to learn while making the purpose of the session clear to another person.

  2. Record the build, accounts and data before exploring. Time-box the session and separate interruptions from actual investigation time rather than presenting elapsed time as test effort.

  3. Keep concise notes on the routes, variations and observations you explored. Mark a question as a question until its expected behaviour has been agreed with the feature owner.

  4. Debrief with a reviewer. Convert reproducible problems into tickets and turn useful discoveries into future regression checks when repeated coverage would justify the cost.

Scope and limitations: Exploration produces observations within a stated scope. Completing a charter does not establish exhaustive coverage or approve the release.

Document preview

# Exploratory session charter

## Mission
Explore [feature or boundary] with [accounts and data] to discover [failure or uncertainty].
- Business consequence if this fails:
- Build / environment / supported client:
- Tester / reviewer / time box:
- Starting state and safe test data:
- Excluded areas:

## Investigation prompts
- What changes for another role or organisation?
- What happens after cancellation, interruption or a repeated action?
- Which empty, expired, malformed or boundary values matter?
- Does keyboard operation expose a different failure?
- Which assumption in the specification needs confirmation?

## Session notes
| Time | Variation explored | Observation | Evidence / next question |
| --- | --- | --- | --- |
| | | | |

Distinguish an observed product problem from a setup failure or an undecided requirement. Capture enough starting state for a later reproduction.

## Debrief
- Paths explored and paths left untested:
- Reproducible defects and private issue links:
- Product questions and decision owners:
- Candidate regression checks:
- Follow-up owner and next review:

## Filled mission — fictional
Explore invitation acceptance with an ordinary member, an organisation administrator and an account in a different organisation to discover permission or state-transition failures. Use staging with synthetic addresses and a 45-minute time box. Exercise new, expired, cancelled and already-used invitations. Exclude delivery-provider resilience from this session and arrange it separately.

Example observation: accepting a cancelled invitation displays a generic error. The charter records the observed response; the feature owner must confirm the intended message before it is classified as a defect. A second tester can repeat the recorded steps, while the original tester investigates whether the account state changed despite the refusal.

Read alongside this worksheet

Get help applying itAll resources