Exploratory Testing
Scripted testing checks what you predicted could break. Exploratory testing hunts for what you didn't — by fusing learning, test design, and execution into one activity, where each result steers the next probe. It is emphatically not "random clicking," and by the end of this page you'll be able to say exactly why: done properly, it's the most skill-dense hour in testing, with a structure that makes it accountable.
Hold two figures in mind: the patrol officer and the detective. The patrol officer walks a fixed route — guaranteed coverage of known ground; that's your scripted regression. The detective walks the scene and follows the evidence wherever it leads — that's exploration. A police force needs both, and so does a test effort; neither replaces the other.
What It Actually Is
In scripted work, design happens at the desk and execution happens later, mechanically separated. In exploration, they run simultaneously: you probe the product, the product answers, and the answer redraws your map — suggesting the next probe no plan could have contained, because the plan didn't know what you just learned. You change dates on a booking; the price recalculates oddly slowly; that slowness is now your lead, and you're testing rapid successive changes — a test that existed nowhere until forty seconds ago. That loop — learn, design, execute, repeat — is the entire definition, and everything else on this page is the discipline that keeps the loop honest.
The Charter: Structure Without a Script
Chapter 5 introduced the format; here it goes to work. A charter aims the session: "Explore booking modifications across state transitions, hunting stuck states and stale calculations — 90 minutes." Where to look, what to hunt, how long. Scoped enough to focus (not "test the app"), loose enough to follow smoke (not "run these twelve steps"). The timebox matters more than beginners expect: ninety minutes with a deadline concentrates attention the way an open-ended wander never does — and it makes exploration plannable, which is what lets it live inside the risk table from two topics ago as a first-class line item.
Session Discipline: Notes and Debrief
What makes it testing instead of wandering is the paper trail. During the session, notes as you go: what you tried, what surprised you, what you'd chase with more time — telegraphic is fine ("modif → price recalc slow ~3s; double-change → total went stale???"). After the session, the debrief: findings become bug reports (the FW-312 anatomy — exploration's discoveries get the same rigor as anyone's), open questions become follow-up charters, and the notes land in the tracker where the team can see what the ninety minutes bought. That closing step is what answers the skeptic's question — "what did the exploring actually produce?" — with artifacts instead of vibes.
Tours: Idea Generators for the Stuck
Twenty minutes into a session, the ideas sometimes dry up. The craft's literature offers tours — named lenses that restart the flow, each a different way of walking the product. The money tour: follow every path money takes — where it's charged, refunded, displayed, rounded. The intern tour: do everything wrong — wrong order, wrong data, abandon halfway, double-click everything (your Chapter 4 catalog, walking). The back-button tour: navigate everything backwards and out of order, because browsers let users do exactly that. Pick a tour, walk it for fifteen minutes, and the session has momentum again. Tours also make fine charters in themselves: "money tour of checkout, 60 minutes" is a complete, aimed mission.
The Session That Found FW-372
The figure above compressed it; here's the fuller story, because it shows the loop earning its keep. Mid-charter, you change dates on a confirmed booking that carries SUMMER15. The price recalculates — correctly, even. But a thought arrives, the kind scripts can't have: the promo required 3+ nights... did anyone re-check that after the change? You shorten the stay to 2 nights. The recalculated total still includes the 15% discount. FW-372: modifications don't revalidate promo conditions — a 2-night stay carrying a 3-night-minimum discount, quietly leaking money on every modified booking. No script contained this test, because writing it would have required already suspecting the bug. The suspicion came from the session — from watching the recalculation happen and asking what it might have forgotten. That's exploration's specific power: it manufactures the suspicions that scripts can only inherit.
Where does exploration fit overall? Alongside scripts, not instead: the regression suite holds the known ground; exploration extends the map. Prime territory: new features (unknown risks), post-fix neighborhoods (what else did the fix disturb?), and anywhere your "huh?" notes from execution point. The risk table assigns it exactly there — tier-1 areas get charters in addition to their workups, because the highest-risk ground deserves both the patrol and the detective.
- "Exploratory testing is unstructured testing." Charter, timebox, notes, debrief — that's the structure. What's absent is the predetermined script, not the discipline. The session produces artifacts a skeptic can hold.
- "It's what you do when there's no time to write test cases." It's a first-class technique that finds what scripts structurally can't — the tests that require suspicions no one had yet. It earns its own line in the risk table, not the leftovers.
- "Experienced testers explore; juniors follow scripts." Juniors explore too — the charter is exactly the training wheels: it aims the session so skill can develop inside a frame. Your first charter is a week-one activity, not a someday one.
- "Exploration findings don't need proper bug reports." FW-372 got the full anatomy — steps, expected-with-source, evidence. Discovery method doesn't change reporting standards; a bug found by hunch still needs to be reproducible by others.
- Exploratory skill is what separates "runs checks" from "finds what matters" — FW-372 was a money leak no script could have caught, found in minute forty of a charter.
- Session-based work is how a junior demonstrates thinking: the charter, notes, and debrief make your judgment visible and reviewable, which scripts never do.
- "How would you test a feature with no requirements and no time?" — the interview scenario — has exploration with a charter as its model answer.
Knowledge Check
What distinguishes exploratory testing from scripted testing?
- Design and execution happen simultaneously, with each result steering the next probe
- Exploratory testing produces no documentation
- Exploratory testing finds less serious bugs than scripts
- Exploratory testing means choosing actions at random
What does the timebox contribute to a session?
- It limits how many bugs can be filed per session
- It concentrates attention and makes exploration a plannable, budgetable activity
- It proves to management that the tester worked the full time
- It prevents the tester from leaving the assigned screen
Why could no script have contained the test that found FW-372?
- The test was too technically complex to script
- Writing it would have required already suspecting the bug — and the suspicion came from the session itself
- The booking modification feature had no documentation
- Scripts are forbidden from testing promo codes
What happens at the debrief?
- The session notes are deleted once the session ends
- Findings become bug reports, questions become new charters, notes go on record
- Every explored path is rewritten as a formal test case
- The tester's speed is evaluated against other testers
You got correct