There is a common misconception: that exploratory testing is "clicking around aimlessly". It's the opposite. Exploratory testing is an approach where design, execution and learning happen at the same time — each result you observe guides the next step. It's discipline, not chaos. And it is precisely the kind of testing that automation can't do: using your head in real time.

Scripted vs exploratory

In scripted testing, someone designs the cases up front and someone else executes them later — thinking and acting are separated in time. In exploratory testing, they are simultaneous:

  SCRIPTED:     think  →  write case  →  (later)  →  execute
                (the test only does what was anticipated)

  EXPLORATORY:  think + execute + learn   (in a loop, at the same time)
                   ▲                    │
                   └──── what I observed guides the next step ────┘

The two are complementary. Scripted testing (and automation) guarantees repeatable coverage of the expected; exploratory testing finds the unexpected — the bug nobody imagined when writing the cases.

Automation verifies what you already know how to ask. Exploratory testing discovers the questions you haven't asked yet.

The problem: how do you manage something so free?

If exploratory testing has no script, how do you plan, measure and report? The answer is Session-Based Test Management (SBTM), created by James and Jonathan Bach. It provides structure without killing freedom, through three ideas:

• Charter (mission statement): a short sentence that defines the session's focus — what to explore and to what end. E.g.: "Explore file upload focusing on invalid formats and sizes."
• Time-boxed session: an uninterrupted, timed block (typically 60–90 min) dedicated to one charter.
• Notes and debrief: a record of what was tested, bugs, questions and ideas — followed by a quick conversation with the team.

This makes exploratory testing reportable: you can say "I ran 3 sessions on checkout, found 2 bugs and 4 business-rule questions" — a concrete metric for a creative activity.

Heuristics: what guides the investigation

Exploratory testing isn't random because the tester uses heuristics — mental shortcuts that point to where defects usually are. Two widely used ones:

SFDPOT (James Bach) — "tour" the product by dimensions:
  Structure   what the product IS (files, code, hardware)
  Function    what it DOES (features, calculations, error handling)
  Data        what it PROCESSES (inputs, outputs, large/empty data)
  Platform    what it DEPENDS ON (OS, browser, dependencies)
  Operations  how it is USED (usage profiles, environments)
  Time        how TIME affects it (timeouts, time zones, concurrency)

RCRCRC (regression) — where to look when time is short:
  Recent      what changed recently
  Core        the product's essential functions
  Risk        the highest-risk areas
  Configuration  configuration-sensitive items
  Repaired    what was fixed recently
  Chronic     what keeps breaking

Heuristics turn "testing for the sake of it" into "testing with hypotheses" — you attack the system from angles where experience says bugs hide.

Where this fits in the strategy

In the Agile Testing quadrants, exploratory testing is the heart of Q3 (tests that critique the product from the business perspective). It doesn't replace the automation at the base of the pyramid — it combines with it: automation covers repetitive regression and frees the human's time for the investigation that only a human does well.

Conclusion

Exploratory testing is critical thinking applied in real time, and session-based testing is what makes it manageable and reportable. Mastering charters, time-boxed sessions and heuristics like SFDPOT and RCRCRC is what distinguishes the QA who "tests the screen" from the one who investigates the product — and it's where the bugs no script predicted show up.