Exploratory Testing and Session-Based Test Management

Exploratory testing is usually defined by what it is not: not scripted, not automated, not repeatable on demand. That framing is why it keeps losing budget arguments. An automated suite produces a number. An exploratory session produces a story, and stories lose to numbers in a status meeting.

Session-based test management exists to close that gap. Jonathan and James Bach defined it in 2000 as a way to make exploratory work countable without making it scripted. A written charter states the mission, a time-boxed session bounds the work, and a structured debrief converts what happened into a record someone else can audit.

Testland's position: exploratory testing is not the informal cousin of real testing. It is the only technique that finds problems nobody thought to specify. The reason it gets treated as unserious is not that it lacks rigor, it is that most teams practice it without any of the accounting that session-based test management already provides.

The three artifacts that make a session auditable

A charter is a mission statement, not a test case. It names an area, a purpose, and often a risk to probe, and it is short enough to fit on one line. Charters that read like scripts defeat the point: the tester's judgment during the session is the technique.

A session is a time box, conventionally 45 to 90 minutes, of uninterrupted work against one charter. The time box is what makes the output comparable across testers and across weeks. Sessions are the unit you count when someone asks how much testing happened.

A debrief is the conversion step. The PROOF format (Past, Results, Obstacles, Outlook, Feelings) gives the debriefer five fields to interrogate, and most of the value comes from refusing to accept vague entries in any of them. Session-based test management: definition and history covers the origin and the mechanics; session-based test management is the audit trail exploratory testing needed covers what the charter-session-debrief loop looks like in a working team; and the debriefer's 60-second test is the five-check pass that separates an action-ready debrief field from filler.

Oracles: how a tester defends a bug call

The hardest moment in exploratory testing is not finding the problem. It is triage, when a developer asks why the observed behavior counts as a bug and the only available answer is "it felt wrong."

Oracles are the principles that turn that instinct into an argument. HICCUPPS-F names nine of them: History, Image, Comparable products, Claims, User expectations, Product itself, Purpose, Statutes, and Familiarity. None of them require a specification, which matters because most of the interesting bugs in a product are not spec violations. HICCUPPS-F: nine testing oracles for defending your bug calls works through each one with the phrasing that survives a triage meeting.

Charters tell a tester where to look. Oracles tell them what counts as a finding when they get there. A team that has adopted one without the other tends to produce either aimless sessions or unarguable bug reports.

Where automation fits

Nothing on this page argues against automated testing. The two techniques answer different questions. Automation answers "does the behavior we already understood still work," which is a regression question. Exploratory testing answers "what is true about this product that nobody has written down yet," which is a discovery question.

Suites that try to make automation do discovery end up enormous, slow, and mistrusted. Teams that try to make exploratory testing do regression end up re-checking the same paths by hand every release. The division of labor is the strategy: automate the answers, explore the questions.

Tooling

The heuristics on this page are packaged as installable skills in Testland's QA marketplace. qa-manual-testing carries the reference material: session-based test management, the HICCUPPS-F oracle catalogue, SFDPOT for varying coverage, Whittaker's exploratory tours, and the manual test debrief format. It also ships a charter-coach and a session-debrief-coach for the two steps teams get wrong most often.

For charter authoring specifically, exploratory-charter-author in the qa-roles org chart writes charters scoped to a single mission rather than the sprawling multi-area charters that turn a session into unstructured clicking.

What this topic does not cover

Scripted manual testing, UAT script authoring, and test case management are adjacent disciplines with different economics, and they are not treated here as exploratory testing under another name. Certification syllabi are likewise out of scope: the vocabulary is useful, but nothing on this page depends on holding a certificate.