Exploratory Testing

---

Origins

Exploratory Testing was named and codified by Cem Kaner in the 1990s and developed extensively by James Bach, Michael Bolton, and the Context-Driven Testing community¹. The discipline pushed back against a then-dominant model of testing as scripted execution — testers running pre-written test cases — arguing that the most valuable testing was the kind a skilled human could do when given freedom and intent.

Kaner defined exploratory testing as simultaneous learning, test design, and test execution. Bach added: each test is informed by the result of the previous one. The defining property is that the tester is using their judgement in real time, not following a script written before they encountered the system.

What Exploratory Testing Isn't

Exploratory testing is often confused with two other things it's not.

• It's not ad-hoc testing: random clicking around without intent. Exploratory testing is structured and goal-directed; it just adapts its structure based on what the tester is learning.
• It's not "testing without writing things down": skilled exploratory testers document their findings, their session goals, and what they learned. The difference from scripted testing is the documentation comes during or after, not before.

What it is: thoughtful, intent-driven investigation of a system, with the tester continuously deciding what to try next based on what they've already seen.

Session-Based Test Management

Jonathan Bach formalized exploratory testing into Session-Based Test Management (SBTM)², which gives the practice the lightweight structure that distinguishes it from ad-hoc testing.

A session is a time-boxed exploration with:

• A charter: what the tester is investigating — "explore the checkout flow with focus on tax calculation edge cases."
• A duration: usually 60-120 minutes uninterrupted.
• Notes: real-time capture of what the tester tried, what happened, what they noticed.
• A debrief: short discussion afterward about what was learned and what should be tested next.

The structure gives exploratory testing the trackability of scripted testing without losing the responsiveness that makes it valuable.

What Exploratory Testing Finds

Different from automated tests in important ways:

• Things nobody thought to test: emergent properties, unexpected interactions, edge cases the spec didn't mention.
• UX problems: things that work but feel wrong — confusing flows, unclear feedback, accessibility issues that pass automated checks.
• Race conditions and timing issues: bugs that depend on the specific sequence of events a script wouldn't reproduce.
• Integration issues with the real world: how the system actually behaves with realistic data, real-world latency, unstable networks.
• Bugs introduced by recent changes: the tester knows what just shipped and probes accordingly.

Automated tests excel at regression — verifying that what used to work still works. Exploratory testing excels at discovery — finding what nobody knew to test for.

Heuristics and Test Tours

Skilled exploratory testers use heuristics — cognitive tools that suggest what to investigate. Examples:

• SFDIPOT (James Bach): Structure, Function, Data, Interfaces, Platform, Operations, Time. A reminder of testing dimensions.
• FEW HICCUPPS (Michael Bolton): Familiarity, Explainability, World, History, Image, Comparable products, Claims, Users' expectations, Product itself, Purpose, Statutes. Quality criteria for noticing problems.
• Test tours (James Whittaker): different "tours" through a feature — the feature tour, the back alley tour, the supermodel tour, the saboteur tour. Each suggests a different angle.

These aren't rules; they're cognitive scaffolding. A tester who knows the heuristics can break out of habitual exploration patterns and find what they would otherwise miss.

Where Exploratory Testing Fits

• New features near release: when automated tests cover the known cases but the team wants discovery of the unknown.
• Post-deploy verification: smoke testing what just shipped, with real production conditions.
• Investigating reported bugs: understanding how a bug actually manifests so it can be reproduced and fixed.
• UX validation: testing how the product feels, not just whether it works.
• Complex integrations: areas where automated test coverage is genuinely hard and human judgement substitutes.

Common Pitfalls

• Confused with ad-hoc: testers "exploring" without intent, charter, or notes. The output is unreliable and the practice gets a bad reputation.
• Used as replacement for automation: skipping automated tests because "we do exploratory testing." Exploratory finds new things; automation prevents regressions. Both are needed.
• No documentation: skilled exploration without notes leaves no trace. Future testers (or the same tester later) can't build on what was learned.
• Restricted to QA: only testers do exploratory testing. Developers, designers, and product people miss the chance to discover issues from their perspectives.
• Session creep: 4-hour exploratory sessions where the tester loses focus and produces shallow results. The 60-120 minute time-box exists for a reason.
• No debrief: the session ends; nobody hears what was found until it's filed as a bug ticket. The team-level learning is lost.

Coaching Tips

Always Use a Charter

Without a charter, exploration becomes ad-hoc clicking. A one-sentence charter focuses the session and makes its output evaluable.

Time-Box Sessions

60-120 minutes. Longer and attention degrades; shorter and depth is missed. The session is the unit; honor the duration.

Document Lightly

Notes during the session capture what was tried and what was learned. Detailed scripts before the session defeat the format.

Always Debrief

A 10-minute debrief at the end multiplies the value of the session. The team learns what was found before reading any bug tickets.

Teach Heuristics

SFDIPOT, FEW HICCUPPS, test tours — these expand the team's exploration vocabulary. Heuristics turn good testers into great ones.

Pair with Developers

Exploratory testing pair-sessions with developers produce immediate fixes and deep understanding. The pairing format works for testing as much as for coding.

Summary

Exploratory testing is what skilled human attention adds that automation can't. Automated tests verify that what used to work still works; exploratory tests find what nobody knew to look for. The teams that treat the two as complements get the benefits of both. The teams that treat them as substitutes — either replacing testers with automation, or replacing automation with exploration — miss what each is for.

The practice has been undervalued in some Agile circles because it doesn't produce CI-runnable artifacts. The artifacts it produces — bug reports, design insights, structural observations — are different but often more valuable per hour invested than another batch of unit tests would be. A skilled exploratory tester is one of the higher-leverage roles on any product team.

Back to Technical Practices