Exploratory testing, done with a charter

Scripted test cases check what you thought to check. But many of the best bugs are found by not following a script — by exploring the app with a curious, skeptical mind, following hunches, trying the unexpected. This is exploratory testing, and done well it is one of the most effective things a manual QA does. Done badly it is just aimless clicking. The difference is a charter — a focus for the exploration — and this lesson is how to explore with purpose.

What exploratory testing is (and is not)

Exploratory testing is simultaneous learning, test design, and test execution — you explore the app, and what you find shapes what you try next. Unlike scripted testing (write cases first, then execute them), exploration is responsive: you notice something odd, you dig; you form a hypothesis about a weak spot, you probe it; each finding suggests the next test. It is where the QA mindset (thinking "how could this break?") is applied live and adaptively.

Crucially, exploratory testing is not the same as ad hoc or unstructured clicking. Aimless clicking with no goal finds little and cannot be reported or repeated. Good exploratory testing is structured — it has a focus, a time box, and notes — while remaining free to follow what it finds. It is disciplined improvisation, not randomness. The tool that provides the discipline is the charter.

The charter: a focus for the session

A charter is a short statement of what a session of exploration will focus on — a mission, not a script. It answers "what am I exploring, and to what end?". Examples:

"Explore the top-up flow under poor connectivity, to discover how it behaves when the network drops at each step."
"Explore the amount and confirmation screens, to discover ways to trigger a double-charge."
"Explore the login and session handling, to discover what happens around expiry and re-login."

A charter is narrow enough to give focus (not "explore the app" — too broad) but open enough to allow discovery (not a step-by-step script). You then time-box the session — say 60 or 90 minutes — and, within it, explore freely towards the charter's mission, following whatever you find. This is session-based test management: exploration organised into chartered, time-boxed sessions with notes, so it is focused, reportable and repeatable — the professional form of exploratory testing, versus "have a click around".

How to explore well

Within a session, the productive habits:

Follow the charter, but chase what you find. If, while exploring connectivity, you notice the balance displays wrong after a rotation, note it and dig — even if rotation was not the charter. Discovery is the point; the charter keeps you from wandering entirely.
Vary systematically. Do not just repeat the happy path. Change one thing at a time — the amount, the network, the order, the device state — and observe. Use the mindset's instincts: edges, unhappy paths, interrupts, sequences.
Take notes as you go. What you did, what you observed, what seemed off, what you want to come back to. Notes make the session reportable ("here is what I explored and found") and let you reproduce a bug you stumbled on (without notes, "I saw it earlier but can't get it back" is a wasted find).
Ask "what if?" constantly. What if the network drops here? What if I tap back now? What if the amount is exactly the balance? Each "what if" is a micro-test.
Notice and pursue "that's weird". A flicker, a wrong number, a delay — the exploratory session is exactly where you have the freedom to chase these, and they often lead to real bugs.

When exploratory testing shines

Exploratory testing is especially valuable where scripted testing is weak:

New or changing features — before requirements are stable enough to script, exploration finds problems (and requirement gaps) fast.
Complex flows and combinations — the interactions and sequences that are impractical to script exhaustively (what happens if you do A, then B, then background the app, then retry?).
Finding the unexpected — scripted tests, by definition, only check what someone thought of; exploration finds what nobody thought of, which is often where the worst bugs are.
Under real conditions — poor networks, device quirks, interrupts — where the messy real world reveals what a clean scripted run does not.

For the mobile-money apps this course targets, exploration around connectivity and money flows — "what happens if I lose the network right after tapping confirm and then retry?" — is exactly where the expensive, subtle bugs (double-charge, lost transaction, wrong balance) are found. A charter aimed at "ways to make a top-up charge twice" and 90 minutes of focused, note-taking exploration will find things no happy-path script ever would.

Scripted and exploratory together

These are not rivals — a good QA uses both. Scripted testing gives repeatable coverage of the known, important cases (and is what you automate); exploratory testing finds the unknown and the unexpected. A sensible approach: scripted (and automated) tests cover the requirements and the critical flows repeatably; exploratory sessions, chartered at the risky and new areas, find what the scripts miss. The findings from exploration often become new scripted test cases (you found a double-charge on retry → write a permanent test case for it). So exploration feeds the scripted suite over time. Neither alone is enough: scripts without exploration only ever check what you already thought of; exploration without scripts has no repeatable safety net. Use the charter to make exploration disciplined, and let it find what scripts cannot.

Check your work

What it is. Simultaneous learning, test design and execution — responsive testing where findings shape the next test; the QA mindset applied live. Not aimless clicking — it is structured (focus, time box, notes) yet free to follow discoveries: disciplined improvisation.

The charter. A short mission for a session ("explore X to discover Y"), narrow enough to focus, open enough to discover; time-boxed, with notes — session-based test management, the professional form.

Exploring well. Follow the charter but chase what you find; vary systematically (one thing at a time, using the mindset's edges/unhappy-paths/interrupts/sequences); take notes (for reporting and reproducing); ask "what if?" constantly; pursue "that's weird".

Where it shines. New/changing features, complex flows and combinations, finding the unexpected, and real conditions (poor network, interrupts) — for money apps, connectivity-and-money-flow charters find the expensive double-charge/lost-transaction bugs scripts miss.

With scripted testing. Both, not either: scripts give repeatable coverage of the known (and are automated); exploration finds the unknown; exploration's findings become new scripted cases. Neither alone suffices.

Practice

Write three exploratory charters for a top-up feature — one aimed at connectivity, one at double-charge, one at session/login — each narrow enough to focus, open enough to discover.
Run a 45-minute chartered, note-taking session on any app, following the charter but chasing what you find; produce a short session report of what you explored and found.
Practise systematic variation: take one flow and change one variable at a time (amount, network, order, device state), noting each result.
Reproduce a bug from notes: find something odd, note exactly what you did, then reproduce it from the notes — feel why notes matter.
Contrast a scripted test case and an exploratory session for the same feature; state what each catches that the other does not.
Turn one exploratory finding into a permanent scripted test case, so the bug can never silently return.

Official documentation

James Bach & Michael Bolton — Rapid / Exploratory Testing — The definitive school of exploratory, session-based testing.
Ministry of Testing — Exploratory testing — Charters, session-based test management, practitioner guides.
ISTQB — Foundation syllabus (experience-based techniques) — Exploratory testing in the standard.

Next: writing a bug report that gets fixed.