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.
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.
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”?