Exploratory Testing Charters
Unstructured exploratory testing is ad hoc. Charter-based exploratory testing is structured, time-boxed, and produces a defensible record of what was explored and what was found.
1 The Hook
A QA tester does 4 hours of "exploratory testing" before a release. Finds 3 bugs. Manager asks: "What did you cover? What did you miss?" She can't answer precisely.
Another tester runs the same 4 hours with 4 charters — one per major area. At the end, she can show exactly: what the mission was, what she explored, what she found, and what she ran out of time for. Both found bugs. Only one produced evidence.
When a defect slips to production, "I did exploratory testing for 4 hours" does not hold up. "Charter ET-03 covered the payment flow using boundary values; the session note records that the 3-decimal-place amount was not tested due to time constraint" does.
2 The Rule
Write a charter before you start exploring. A charter is not a script — it's a mission statement. It defines the scope, the approach, and how you'll know when you're done.
3 The Analogy
A charter is like a dive plan for a scuba diver.
You're not told exactly where to swim — you decide that as you explore. But you know your maximum depth, your time limit, your buddy, and your objective. The plan isn't restrictive; it's what makes the dive safe and purposeful. A diver without a plan is a risk to themselves. A tester without a charter is a risk to the release.
4 Watch Me Do It
Charter format: Explore [area] using [approach] to discover [information]
Three charters for a NZ banking app pre-release session:
Explore the international payment flow using boundary values on the amount field (minimum NZD transfer, maximum daily limit, amounts with 3 decimal places) to discover how the system handles edge cases in amount validation.
Time box: 60 min Tester: Aroha M Risk area: Financial calculation correctness
Explore the login flow using multiple concurrent sessions from different devices to discover how the system manages session conflicts and logout behaviour.
Time box: 45 min Tester: James T Risk area: Security — session hijacking, ghost sessions
Explore the transaction history view using different date ranges and search terms to discover filter accuracy, pagination behaviour, and performance under a large transaction set.
Time box: 60 min Tester: Aroha M Risk area: Data display accuracy, performance
Session notes template:
| Field | What to record |
|---|---|
| Charter | The mission statement (verbatim) |
| Tester | Name and date |
| Duration | Actual time spent |
| Areas covered | What you actually explored (may diverge from charter) |
| Bugs found | Bug ID or description + severity |
| Issues / questions | Unclear behaviour, risks, questions for the team |
| Not covered | What the charter intended but time ran out |
5 When to Use It
- Before each release — write charters the sprint before to focus on the highest-risk areas
- When testing a new feature with unclear requirements — the charter defines what you're trying to learn, not what you're trying to confirm
- When time is limited and you need to maximise coverage — time-boxed charters force prioritisation
- When you need to document what was explored for sign-off — charters + session notes are the audit trail
- When onboarding a new tester to a complex area — give them a charter, not a blank slate
6 Common Mistakes
❌ I used to think: exploratory testing means testing without documentation.
Actually: undocumented exploratory testing is indistinguishable from random clicking. Charters and session notes are the minimum viable documentation. They don't slow you down — a charter takes 5 minutes to write and saves an hour of explaining when something slips to production.
❌ I used to think: a charter should specify exactly what to test.
Actually: a charter sets the mission, not the steps. "Click button A, then B, then C" is a script, not a charter. The tester decides how to explore within the defined area and time box. The charter gives freedom within a boundary — that's the point.
❌ I used to think: exploratory testing is for when you don't have time for proper testing.
Actually: charter-based exploratory testing is proper testing. It's the technique that finds defects scripted tests miss — because it combines tester skill and intuition with systematic coverage documentation. It's not a fallback; it's a primary technique for high-risk areas.
7 Now You Try
Write 3 charters for a pre-release exploratory session on a NZ government online driver licence renewal service. The service allows: address update, payment, photo upload, and document download. You have 3 hours total. Each charter should follow the format: Explore [area] using [approach] to discover [information], and include a time box and the risk area being targeted.
8 Self-Check
Click each question to reveal the answer.
Q1: What is the difference between a charter and a test script?
A test script specifies exactly what steps to take and what to check at each step. A charter defines the mission — the area to explore, the approach, and the information goal — but leaves the specific steps to the tester's judgement during the session. A charter enables adaptation; a script does not.
Q2: Why is the "Not covered" section of a session note important?
It documents the gaps explicitly rather than leaving them invisible. When a defect slips through, the question is always "was this area tested?" A session note that records "3-decimal-place amounts not covered — ran out of time" means the team can make an informed decision: accept the risk, schedule another session, or block the release. Undocumented gaps are invisible risks.
Q3: You have 4 hours before a release. How many charters should you write, and how long should each time box be?
As a guide: 60-minute time boxes work well — they're long enough for productive exploration but short enough to keep focus. Four charters of 60 minutes each. Spend 15 minutes upfront writing charters and reviewing with the team to prioritise highest-risk areas, then 45 minutes per session. Leave the last 15 minutes for writing up session notes across all four.
9 ISTQB Mapping
ISTQB CTFL v4.0, Section 5.1.3 — Charter-based exploratory testing (also known as Session-Based Test Management, SBTM). Foundation-level testers are expected to understand the charter format, session notes, and the role of exploratory testing within a test strategy.
Related: CTAL-TA v3.1.2, Section 3.1 — Exploratory testing as a dynamic technique; integration with risk-based test planning.