What Is Exploratory Testing? The Layer That Grows

A script can only fail the way its author imagined it could fail. Everything else, the sequence nobody scripted, the two features that shipped eighteen months apart and never got introduced to each other, needs a person paying attention in the moment.

This is written for the engineer, SDET, or release owner who has to decide whether a build is actually ready, or who just got handed an exploratory pass to run before sign-off. It is not written for someone building a QA team's suite-allocation strategy, someone asking whether an AI-generated suite is real testing or test theater, or someone choosing edge-case inputs for a single test case. Those are real questions with their own answers, one level up or one level down from this one.

What Exploratory Testing Actually Is

Exploratory testing has a specific origin, not just a vibe. Cem Kaner coined the term in the 1980s, borrowing the idea from statistician John Tukey's "exploratory data analysis." James Bach, who has spent decades refining the practice with his brother Jonathan, says it plainly: "I didn't coin the term exploratory testing. Cem Kaner did that in the 80's." Kaner laid out the formal definition himself, in a 2006 QAI keynote, and it is still the formulation the field quotes: "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project." Bach and Michael Bolton later argued, in "Exploratory Testing 3.0", that the practice should simply be called testing. The shorter version Bach reaches for just as often: simultaneous test design, execution, and learning.

That word, simultaneous, is the entire mechanism. A scripted test separates the three activities in time: designed last week, executed today, and whatever gets learned from a failure happens afterward, in a bug report. Exploratory testing collapses all three into the same minute. A tester tries something, watches what happens, updates their model of the product, and lets that update steer the very next thing they try.

Learning, design and execution run in the same loop, each one steering the next.

None of that requires wandering aimlessly, which is the most common misreading of the practice. Session-based test management, the structure James and Jonathan Bach built together at Hewlett-Packard, wraps exploratory testing in a charter, a time box, and a session sheet, so the freedom stays bounded and the output stays auditable.

Exploratory Testing vs Scripted Testing: Why the Usual Framing Is Backwards

Most explanations of exploratory testing place it at the bottom of a maturity ladder: manual first, exploratory in the middle, automation as the destination, on the assumption that the more scripted checks a team has, the less exploratory testing matters.

That assumption has the causality backwards, and it shows most clearly once code-generated checks enter the picture. A scripted check, whether written by hand or generated from the codebase, can only encode an expectation that already exists. Someone, or something reading the code, had to know what "correct" looked like before it could write a check that verifies it. James Bach and Michael Bolton draw this same line in Testing and Checking Refined, separating the mechanistic confirmation of a proposition that's already known from the open-ended work of learning about a product by experiencing and experimenting with it. Exploratory testing does the opposite: it forms expectations that did not exist yet, by putting a person in front of the running product with a hunch and watching what happens when reality disagrees with the mental model.

A scripted check confirms a known expectation. A session goes looking for one that doesn't exist yet.

Once scripted checks get cheap to produce, generated from the codebase and folded into a regression suite kept current automatically as the code changes rather than going stale, the two axes stop competing for the same hours. What's left over, the parts of the product the spec never mentioned, is not a shrinking category as generation improves. It is a growing share of the testing budget, because it was never a category a script was eligible to cover. As scripted checks stop being scarce, exploratory time stops being the thing squeezed out by automation and becomes the highest-leverage hour a testing budget has.

That reframing is aimed at whoever decides, for this build, where the human attention on a release goes right now, not at redesigning how a QA org allocates hours across a whole portfolio.

An Exploratory Testing Charter Example, Filled In

A charter is the difference between exploratory testing and clicking around hoping to notice something. James Bach's format compresses to one sentence: explore a target, using stated resources, to discover specific information, with a time box, scope boundaries, and a starting hunch filled in around it.

Here's a session against a concrete product: TeamBoard, a Kanban-style project management tool, and its bulk card-move feature, selecting several cards at once and moving them together across columns or boards.

The Charter: Six Fields, Filled In

Charter field	Value
Target	Bulk move across boards, multi-select and shortcut
Resources	Seeded board, 40 cards, mixed owners
Information goal	Where bulk actions bypass single-move validation
Time box	90 minutes, one normal session
In scope	Multi-select drag, shortcut, cross-board moves
Out of scope	Single-card moves, admin UI, mobile app

The tester's starting hunch: the keyboard-shortcut move and the drag-and-drop move shipped six months apart, built by different engineers, and probably don't share a validation path. That hunch isn't a fact yet. It's the reason to point ninety minutes here instead of somewhere else, and confirming or killing it is the session's job.

The Session Sheet: What Ninety Minutes Produced

Time	Tried	Observed	Outcome
09:00-09:15	Bulk-moved 6 cards via drag	Due dates cleared on 2 cards	Bug logged
09:15-09:30	Repeated move, non-Done columns	Due dates persisted	New charter spun off
09:30-09:45	Same move via keyboard shortcut	Only 1 of 6 cards moved	Bug logged
09:45-10:00	Bulk-moved cards I can't edit	Move succeeded anyway	Bug logged, high severity
10:00-10:15	Bulk-moved 25 cards, larger batch	All correct, no progress feedback	Note, not a bug
10:15-10:30	Wrap-up and review	Three bugs, one new charter	Session closed

Three bugs and one new charter came out of ninety minutes. None were things a generated check would have caught, not because the checks were badly written, but because nobody, human or agent, had written an expectation for what a due date should do when six cards cross a status boundary in one gesture.

A finding doesn't just close a session. It routinely opens the next charter.

That's what a charter produces: not a pass or fail signal, but new information the product never had documented anywhere.

What to Explore When the Scripted Checks Are Free

Once smoke, regression, and acceptance paths are all covered by checks that regenerate themselves, the question stops being whether to explore and becomes where to point the one resource that doesn't scale: a person's attention. The rule: point it at surfaces a script was never eligible to cover, not at surfaces it already covers well.

Four criteria find those surfaces, and they map directly onto the TeamBoard session above. Where the spec stays silent is the first: nobody wrote a requirement for what a due date should do when a card crosses into "Done" via a bulk move, so no check, generated or hand-written, encodes an expectation either way. Where two features first meet is the second: the drag handler and the keyboard-shortcut handler were each tested alone, but nobody chartered the intersection, which is exactly where the permission bypass turned up. Where the tester's mental model and the code's model disagree is the third, and the most productive one to chase deliberately: assume two paths share a validation step, then go find out whether they actually do. Where a check would need business judgment to know it's wrong is the fourth: a bulk move that silently skips a permission check is numerically successful, the request returned success, and it's only wrong if you know what should have been blocked.

The boundary moves right as generated coverage grows. The four criteria decide where attention goes on the other side.

None of that is a checklist to run once. It's a filter for picking the next charter, and it stays useful for as long as scripted coverage keeps expanding.

How Autonoma Clears the Scripted Layer So You Can Explore

Everything up to this point, the definition, the charter, the heuristic, describes work that stays human by definition. An agent that generates and runs a check is not doing exploratory testing, no matter how well it drives a browser, because a generated check encodes an expectation that already existed somewhere: in the code, in a spec, in a pattern the agent inferred while reading the codebase. Exploratory testing is specifically the activity of forming an expectation that didn't exist yet. Those are different jobs, and treating them as interchangeable is exactly the kind of category error a testing budget cannot afford to make.

What Autonoma does is narrower, and we think more honest: it clears the scripted layer so the human hours in a release cycle land on exploration instead of on maintaining a smoke suite or re-running a regression pass by hand. Our agents read the codebase directly and generate the checks that cover what's already specified, the login flow, the primary write and read paths, the acceptance criteria a ticket already states, then run them against a live preview environment rather than a saved snapshot, which is what lets a check survive a UI change instead of breaking on the next deploy. On every pull request, the Diffs Agent re-derives that suite from what changed, so nobody spends a sprint rewriting checks a code diff already explains. None of that is exploratory testing. All of it is time exploratory testing would otherwise have to spend covering ground a script was always capable of covering.

Mapped onto the TeamBoard session above: Autonoma is what keeps the smoke and regression suite around the bulk-move feature current as the code changes, not what discovers that a keyboard shortcut silently drops four of six selected cards. That discovery needed a charter, a hunch, and ninety minutes of a person paying attention, and it still does.

What Exploratory Testing Is Not

Exploratory testing gets confused with a few neighboring practices often enough that it's worth drawing the lines explicitly, since each one sits in the same release cycle without doing the same job.

It is not ad hoc testing, even though both look like someone poking at the app from the outside. Ad hoc testing has no charter, no time box, and no session sheet, so nothing about it is reviewable after the fact, and nothing about it compounds into a next session. Exploratory testing produces an artifact; ad hoc testing produces a memory, which fades by the next standup. The difference isn't the tester's skill. It's whether the session left something behind that a second person could read.

It is not validation testing, even though both ask whether a product actually serves the user rather than just matching a spec. Validation testing asks that question against a stated set of user needs, usually as a planned pass at a defined checkpoint, with an oracle someone agreed on in advance. Exploratory testing asks the same underlying question continuously and informally, with the tester's own judgment standing in for the oracle, and it often finds the gap a planned validation pass was set up to catch before that pass ever runs.

It is not acceptance testing, even though a good exploratory session sometimes turns up exactly the kind of gap an acceptance gate exists to catch. Acceptance testing checks a build against criteria someone already wrote down and agreed to; a charter goes looking for the criteria nobody wrote down yet, which is why a strong exploratory pass often becomes the source of next quarter's acceptance criteria rather than a check against this quarter's.

And it isn't the functional vs. non-functional split either. A charter can wander into either territory in the same session (the TeamBoard session above turned up a functional bug, the dropped selection, and a usability gap, the missing progress feedback, in the same ninety minutes), because a human's attention doesn't respect that boundary the way a generated suite does. A script has to be told which category it's checking. A tester just notices.

The debate over whether manual testing still matters next to AI-generated suites usually assumes "manual" means someone running the same script by hand, slower and more error-prone than a machine doing the identical thing. Exploratory testing is the part of manual testing that debate keeps skipping over: not a slower way to run an existing check, but the only way to find the check that doesn't exist yet. Collapsing those two into one "manual" bucket is how a real, durable skill ends up discarded alongside genuinely obsolete busywork.

None of this is an argument against generating checks. It's an argument about where the time those checks free up should go. A build with a self-maintaining smoke and regression suite still needs someone to open it up, form a hunch, and spend an unscripted hour finding out where the product's behavior and its documentation quietly disagree. That hour doesn't get cheaper as generation improves; it gets scarcer to justify, right up until a team notices it's the only hour on the calendar actually producing new information about the product. If Autonoma is already handling the scripted layer for your team, the next Monday-morning move is picking the corner of the product nobody's chartered yet, not adding more generated checks to a suite that's already current.

Frequently Asked Questions