Exploratory Testing
Simultaneously design, execute, and learn. Exploratory testing isn’t random clicking — it’s structured investigation guided by a charter and the tester’s growing understanding of the system.
1 The Hook
A team in Christchurch ships a school-enrolment portal with a thick set of scripted test cases, all green. Every field validated, every form submitted, every box ticked. Two days after go-live, a parent rings the school in tears: she added her second child, went back to edit the first child’s details, and the portal silently overwrote child one with child two’s information. Both records now showed the same kid.
No scripted test caught it, because no script told anyone to add a child, then go back and edit an earlier one. The script tested each step in isolation; the bug lived in the messy real-world sequence a human actually does. A tester following their nose — "what happens if I do these out of order?" — would have found it in ten minutes.
That is the gap exploratory testing fills. Scripts check the paths you already thought of. Exploratory testing finds the paths you didn’t — by letting a thinking tester design the next test based on what the last one just revealed.
2 The Rule
Design and run tests at the same time, steering each new test by what the last one taught you — but keep it disciplined with a charter, a time box, and notes. It is structured investigation, not random clicking.
3 The Analogy
A detective working a case, not a clerk reading a form.
A clerk processes the same checklist for every file: tick, tick, tick, done. A detective starts with a brief — "find out how the intruder got in" — and lets each clue decide the next question. A scuff on the windowsill sends them to the garden; a footprint in the garden sends them to the fence. They are not wandering aimlessly; they have an objective and they take notes, but the path is shaped by what they keep finding.
Exploratory testing is detective work on a build. The charter is the brief, the notes are the case file, and every surprising result is a clue that points you at the next test. A scripted test plan is the clerk’s checklist — useful, but it never follows a clue it wasn’t told about.
What it is
Exploratory testing (ET) is an approach where test design and test execution happen at the same time, guided by the tester’s real-time understanding of the system. It’s most powerful when specifications are incomplete, the system is complex, or you want to find bugs that scripted tests miss.
The core idea: you learn about the system by testing it, and you use what you learn to guide your next test. Unlike scripted testing, you’re not following a predetermined script — you’re investigating.
Not unstructured: exploratory testing is often confused with "ad hoc" testing. Ad hoc has no structure. Exploratory testing has a charter, a time box, and a session report. It’s disciplined investigation, not random clicking.
The charter
A charter is a short statement of what you’re exploring and what you’re looking for. It gives the session focus without scripting every step.
Format: "Explore [target] using [resources/approach] to discover [information]"
| Charter | Focus area |
|---|---|
| Explore the checkout flow using edge-case payment data to discover how the system handles declined cards and partial payments | Payment error handling |
| Explore user profile settings using a newly registered account to discover what can be changed and how data is validated | Account management |
| Explore search functionality using unusual characters and very long strings to discover input handling | Input validation |
Running a session
- Write your charter — define scope and focus before you start.
- Set a time box — typically 60–90 minutes. Long enough to go deep, short enough to stay focused.
- Explore and take notes — what you tried, what you noticed, what surprised you. Notes are key evidence.
- Log bugs as you find them — don’t just mentally note them; write them up properly during the session.
- Debrief — at the end, review what you found, what you didn’t cover, and what new charters to create.
Session reporting (SBTM)
Session-Based Test Management (SBTM) formalises exploratory sessions. Each session produces a Session Sheet with: the charter, duration, tester, bugs found, coverage notes, and a ratio of time spent on setup vs exploration vs bug investigation.
This gives management visibility into exploratory work — it’s no longer a black box.
When to use it
- Early in a project when specs aren’t final — learn the system
- After major refactors — systematic regression may miss emergent bugs
- When you suspect bugs that scripted tests won’t find
- New product areas — before writing formal test cases
- Time-constrained testing — maximum value per hour
ISTQB mapping
| Ref | Topic |
|---|---|
| 4.4.3 | Exploratory Testing — simultaneous design and execution |
| 4.4.3 | Charter-based sessions, time-boxing, session reporting |
| CTFL-AT | Exploratory testing in Agile teams — sprint-level application |
Practice this technique: Try Senior Practice 10 — Exploratory charter, Senior Practice 03 — Async & loading states.
NZ example — Charter for testing a NZ government service
NZ government services (IRD myIR, NZTA Waka Kotahi portal, RealMe) have specific testing considerations that automated tests won’t have.
| Charter element | Detail |
|---|---|
| Charter | Explore the payment submission flow using NZ bank account formats (including Rural Bank, Kiwibank, TSB) to discover whether account validation accepts all valid NZ account structures and rejects invalid ones |
| Session note: account format | Does the system accept the BB-bbbb-AAAAAAA-SS format? Does it accept accounts from all NZ banks (Kiwibank, TSB, SBS have different prefix ranges)? |
| Session note: currency | Does it display amounts in NZD correctly (two decimal places, $ symbol)? |
| Session note: public holidays | Does it handle the NZ public holiday edge case — payments submitted on Waitangi Day, ANZAC Day? |
The charter keeps the session focused — you’re not randomly clicking, you’re investigating a specific quality risk with NZ-specific knowledge that automated tests won’t have.
4 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
Read the two session descriptions below. Decide which one is genuine exploratory testing and which is just ad hoc clicking, and name the specific things that make the difference.
Session B: "I just clicked around the site for a while after the build dropped, tried a few things that came to mind, found something odd but I’m not totally sure how I got there, and moved on."
Show model answer
Session A is exploratory testing. Session B is ad hoc.
What makes the difference:
- Charter: A has a stated focus ("how the listing flow handles draft listings"); B has none.
- Time box: A is bounded at 90 minutes; B is "a while".
- Notes / reproducibility: A recorded what was tried, so findings are reproducible; B "isn’t sure how I got there" — a bug nobody can reproduce.
- Output: A produced logged bugs, coverage notes, and follow-up charters; B produced an unverifiable "something odd".
The point: exploratory testing is disciplined investigation — charter, time box, notes, debrief. Ad hoc has structure removed. Same freedom to follow clues; very different rigour.
The charter below, written for an IRD myIR portal, is too vague to guide a session. Rewrite it in the Explore / Using / To discover format so it has a specific target, a concrete approach, and a real information goal.
"Explore the whole portal using various inputs to find bugs."
Rewrite as a strong charter:
Show model answer
Strong charter (one good version): Explore — the GST return submission flow Using — returns with edge-case amounts (zero GST, a refund/negative position, and an amount above the field’s apparent limit), plus saving a draft and resuming it later To discover — whether the portal calculates and displays the GST position correctly, preserves a saved draft accurately, and gives error messages specific enough for a user to self-correct. Why it is stronger: - Specific target: "the GST return submission flow", not "the whole portal". - Concrete approach: named edge-case data and a draft-resume sequence, not "various inputs". - Real information goal: named quality risks (calculation correctness, draft preservation, error-message quality), not "find bugs". A charter another tester could pick up and run without asking what you meant.
You have just finished a 60-minute exploratory session on a NZTA Waka Kotahi vehicle-licence (rego) renewal flow. Write the SBTM session sheet for it: charter, tester, duration, a rough time split (setup vs exploration vs bug investigation), bugs found, coverage notes, and any follow-up charters. Make it realistic.
Show model answer
SBTM session sheet (example): Charter: Explore the rego renewal flow using vehicles with different statuses (current, lapsed, on hold) and overseas/no-email accounts to discover whether the flow correctly prices the renewal term and handles accounts that can’t receive an email confirmation. Tester / Duration: A. Tester / 60 minutes. Time split: setup ~15% (test account, sample vehicles), test design & execution ~65%, bug investigation ~20%. Bugs found: 1. Lapsed-vehicle renewal showed the current-vehicle price for one frame before correcting — confusing flash of wrong total. 2. Account with no email reached the confirmation page with no way to get a receipt; no warning earlier in the flow. Coverage notes: covered 3-, 6-, and 12-month terms for current and lapsed vehicles, and the no-email path. Did NOT cover payment decline handling or the "on hold" vehicle status — out of time. Follow-up charters: - Explore the renewal payment step using declined and partially-authorised cards to discover how failures are surfaced. - Explore "on hold" vehicle renewals to discover whether the flow blocks or misprices them. A good sheet makes the session auditable: a manager can see what was covered, what wasn’t, and what to do next — exploratory work is no longer a black box.
Self-Check
Click each question to reveal the answer.
Q1: What is the core idea that separates exploratory testing from scripted testing?
Test design and execution happen at the same time. You learn about the system by testing it and use what you learn to choose the next test — instead of following a script written before you understood the system. That lets you find paths nobody thought of in advance.
Q2: How is exploratory testing different from ad hoc testing?
Exploratory testing has a charter, a time box, notes, and a debrief — it is disciplined investigation. Ad hoc has no structure. Both follow the tester’s judgement, but only exploratory testing produces reproducible findings and a record of what was covered.
Q3: What are the three parts of a good charter, and why does each matter?
A specific target (so another tester could pick it up), a concrete approach or data type (not "various inputs"), and a named information goal or quality risk (not just "find bugs"). Together they give the session focus without scripting every step.
Q4: What does Session-Based Test Management (SBTM) add, and why do managers value it?
SBTM produces a session sheet per session — charter, duration, tester, bugs found, coverage notes, and a time split across setup, testing, and bug investigation. It makes exploratory work auditable and visible, so it is no longer a black box to management.
Q5: Name two situations where exploratory testing is the right tool to reach for.
Early in a project when specs aren’t final (you learn the system as you test), and after a major refactor where systematic regression may miss emergent bugs. It also shines when you suspect bugs scripted tests won’t find, in brand-new product areas, and under tight time constraints where value-per-hour matters.
Write a charter from a mission
Using the Explore / Using / To discover charter format, fill in each part below. Complete all three to see the model answer.
Model charter
“Explore the payment submission flow using NZ bank account numbers from all major banks (ANZ, ASB, Kiwibank, TSB, Westpac) and at least two invalid formats to discover whether account validation correctly accepts valid accounts and rejects invalid ones, and whether error messages are specific enough for users to correct their input.”
Your charter doesn’t need to match this exactly. A good charter has: a specific target (not “the whole site”), a specific approach (not “various inputs”), and an information goal (not “find bugs” — what specifically?).
Self-check
- ✓ Is your target specific enough that another tester could pick it up?
- ✓ Does your “using” describe a concrete approach or data type?
- ✓ Does your “to discover” name a specific quality risk, not just “find bugs”?