What is exploratory testing, and how do you make it structured and accountable?

Exploratory testing is testing where learning about the product, designing tests and executing them happen at the same time, and each result shapes the next test. It is not “random clicking”: a skilled tester is deliberately looking for risk using domain knowledge, heuristics and observation. It complements scripted and automated checks, which are good at confirming known expectations but poor at finding problems nobody anticipated.

Making it structured: session-based test management

The common way to make exploration accountable is session-based test management (SBTM), described by Jonathan and James Bach:

1. Charter: a one-line mission. A popular template from Elisabeth Hendrickson’s Explore It! is “Explore target with resources to discover information”. Example: “Explore bulk CSV import with malformed and very large files to discover data loss or unclear errors.”
2. Time-box: typically 60 to 120 minutes, uninterrupted.
3. Session notes: what you tested, how, what you observed, bugs, questions, and ideas for new charters.
4. Debrief: a short conversation with a lead or the team about coverage, findings and what remains risky.

Metrics can be kept lightweight, such as the share of time spent on testing versus setup versus bug investigation, which shows when the environment, not the product, is the bottleneck.

Where test ideas come from

• Heuristics and mnemonics: SFDIPOT (Structure, Function, Data, Interfaces, Platform, Operations, Time) for product coverage; CRUD for data; Goldilocks (too small, too big, just right) for inputs.
• Tours: follow the money, the data, the configuration, the “back alley” of rarely used features.
• Oracles: how you recognise a problem, for example inconsistency with comparable products, with the product’s own history, with claims in documentation, or with user expectations.
• Interruptions and state: refresh mid-flow, double-submit, go offline, open in two tabs, change permissions while a session is active.

When it adds the most value

• New or rapidly changing features where scripts would be out of date before they are finished.
• After automation passes, to look for what automation does not check (layout, usability, odd state).
• Investigating a vague customer report.
• Learning a product quickly when joining a team.

Findings often feed back into automation: a bug found by exploration becomes a regression test.

Example session note

Charter: Explore CSV import with malformed files to discover data loss or unclear errors
Duration: 90 min (testing 70%, setup 20%, bug investigation 10%)
Covered: empty file, header only, BOM, semicolon delimiter, 50k rows, duplicate IDs, quoted newlines
Bugs: #4312 rows after a quoted newline are silently dropped
Questions: should duplicate IDs update or reject? (asked PO)
New charters: import with non-UTF-8 encodings; concurrent imports by two admins

What interviewers look for

• A definition that includes design and learning, not just “no test cases”.
• Charters, time-boxes and debriefs: evidence it can be planned and reported.
• Concrete heuristics or tours you actually use.
• How exploration and automation feed each other.

Common mistakes

• Equating exploratory testing with ad hoc testing.
• No record of what was covered, so the work is invisible to the team.