Generate an Exploratory Testing Charter with AI
Returns a Session-Based Test Management charter for a feature area, including a focused mission statement, in-scope areas, applicable testing heuristics by acronym (FEW HICCUPPS, SFDIPOT, RIMGEA), timebox, environment, and a structured notes template.
When to use it
- You're starting an exploratory testing session on a new or changed feature.
- You want to focus a 60–120 minute session rather than 'just clicking around'.
- You're coaching a junior tester through heuristic-based exploration.
- You need to document exploratory sessions for compliance or release reviews.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a context-driven test consultant trained in Session-Based Test Management (SBTM) by James Bach and Jonathan Bach. You apply heuristics like FEW HICCUPPS (oracles), SFDIPOT (product elements), and RIMGEA (bug reporting) explicitly by name.
</role>
<context>
The team runs exploratory testing in 60–120 minute timeboxed sessions. Every session has a charter that focuses the tester on a mission. The charter does NOT list specific test cases — that's the tester's job during the session. The charter does cite heuristics by acronym + expansion so the tester knows which oracles to apply.
</context>
<task>
Create an exploratory testing charter for the feature/area below. The charter must contain:
1. Mission statement — one sentence, action verb leading
2. In-scope areas (3-6 bullets)
3. Out-of-scope (1-3 bullets, explicit)
4. Applicable heuristics by acronym + full expansion (3-5 heuristics)
5. Timebox (60, 90, or 120 minutes)
6. Environment, build, data prerequisites
7. Notes template (sections to capture during the session)
</task>
<input>
Feature or area to explore: {feature}
Recent changes / known risk: {risk}
Time available: {time}
</input>
<constraints>
- This is a CHARTER, not a test plan. No specific test cases. No step-by-step procedures.
- Cite heuristics by acronym AND full expansion (e.g., "FEW HICCUPPS — Familiar, Explainable, World, History, Image, Comparable, Claims, User-expectations, Product, Purpose, Statutes").
- Mission statement must start with a verb (Explore / Investigate / Survey / Stress).
- Include at least one risk-based heuristic if recent changes are known.
</constraints>
<output_format>
Markdown document with 7 sections matching the task list. Followed by a 1-sentence "Debrief prompt" — the question the tester should answer when the session ends.
</output_format>
Before writing, decide which 3-5 heuristics are most relevant given the feature and risk.Example
Common pitfalls
- Model produces specific test cases instead of a charter — it confuses 'exploratory' with 'manual'. Reject and re-prompt with stronger 'NO test cases' constraint.
- Heuristics get listed by acronym only, without expansion — testers can't apply them. Require full expansion in constraints.
- Timebox defaults to 60 min regardless of feature size — provide explicit timebox in input.
- Out-of-scope is left empty, leading to session sprawl. Always require at least one explicit out-of-scope bullet.
Tips
- Run this prompt at the start of each iteration; charters age fast as features change.
- Pair the charter with a debrief — schedule a 15-min session-end review with whoever requested the testing.
- If the mission isn't a single sentence with a verb, it's too vague — re-prompt.
- When recent-changes are unknown, ask the model to add a 'risk hypothesis' section as a substitute for missing risk data.
FAQ
A test plan answers 'what will we test and how do we know we're done?' at a release level. A charter answers 'what should I focus on in the next 90 minutes?' at a session level. Test plans get written once per release; charters get written 5-10 times per release.
Related prompts
Generate Test Cases from Requirements
Given one requirement, the model returns a structured suite of 8-10 test cases — ID, title, preconditions, steps, expected result, priority, and the design technique that generated each case — covering happy path, negative scenarios, boundary values, equivalence partitions, and edge cases.
Open →Risk-Based Testing Prioritization
Reads a feature list and outputs a prioritization matrix with four weighted dimensions (business impact, technical complexity, usage frequency, defect history) scored 1-5, total weighted score, recommended test execution order, and tie-break rule.
Open →Create BDD Scenarios in Gherkin
Reads a user story and returns Cucumber-compatible Gherkin scenarios covering happy path, error scenarios, and at least two edge cases. Uses Scenario Outline with Examples tables when 2+ data variations exist. Forbids UI implementation detail in Then steps.
Open →Write a Detailed Bug Report
Takes a free-form issue description (Slack message, email, support ticket) and returns a structured bug report following the AQA Pro Bug Report Template — clear `[Component] Verb-noun` title, environment, separate severity and priority, numbered atomic repro steps, expected vs actual, and suggested investigation areas.
Open →