Exploratory Testing: Charters, Heuristics and Oracles

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 (SBTM): definition, sessions and metrics covers the origin, the session sheet, the TBS metrics, and where the method breaks; Exploratory testing charter: template and examples has a copy-ready charter card and shows 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.

Skills that package the charter, session and debrief

The heuristics on this page are packaged as installable Claude Code skills in Testland's QA marketplace, collected in qa-manual-testing. The exploratory-testing skill owns the whole cycle, from budgeting the tester hours available before a release to the debrief that closes each session. Its reference sections carry the material this page discusses: the charter card, the session sheet and TBS metrics, the PROOF debrief, the HICCUPPS-F oracle catalogue, SFDPOT for varying coverage, and Whittaker's exploratory tours.

For charter writing specifically, exploratory-charter-author turns a feature spec, a risk area, or a bug cluster into one charter: a one-sentence mission, three to seven scoped areas, and a time-box. That keeps a session aimed at a single mission rather than the sprawling multi-area charters that turn it into unstructured clicking. When a session turns up a path worth re-checking every release, the test-script-quality-critic agent reviews the resulting manual script for vague preconditions, bundled steps, and missing expected results before it joins the regression baseline.

When there is no story or spec at all, only a running feature, test-case-from-live-feature in qa-process pairs structured exploration with HTSM product elements, Bolton's HICCUPPS consistency oracles, and the ISO/IEC 25010 quality characteristics to produce a reviewable case matrix. How these skills install and fit into a session with Claude Code is covered under Claude Code for QA.

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.