Exploratory testing is not random clicking

The fastest way to lose an argument about exploratory testing is to describe it badly. What most managers hear is "click around until something breaks", and they are right to distrust that. It has no scope, no record, and no way to tell a thorough hour from a wasted one.

The version that works has all three, and it takes about two minutes of setup.

A charter is the whole difference

Every session starts with one written sentence: what you are exploring, with what, and what you are looking for. Not a test case, and not a script. A direction.

Explore the invite flow, with expired and reused links, to discover states the UI does not explain.

That sentence does three jobs. It stops the session drifting into whatever is interesting. It tells the next person what was already covered. And it turns "we tested billing" into something a reader can actually check.

Time box it, then stop

Sixty minutes, ninety at the outside. The value of a session drops sharply after that, because you stop forming new ideas and start re-walking old ones.

A hard stop also protects the schedule. Unscripted work with no end time is the reason exploratory testing gets cut first when a release gets tight. Two booked sessions of an hour survive a busy week. "Some time for exploration" does not.

Notes during, not after

Write while you test. A running log of what you tried, what you saw, and what you want to come back to. It costs a few seconds per line and it is the difference between a finding and a memory.

• What you did, in enough detail to repeat it.
• What surprised you, even when it turned out to be correct. Surprise is the signal.
• Questions, which usually become the next charter.
• Bugs, filed properly afterwards, with the six fields a ticket owes a developer.

At the end of the session the notes are the deliverable. The bugs are a by-product.

What it finds that a script cannot

A scripted test can only fail in the way it was written to fail. It checks the states someone already thought of, which is exactly the set of states that already work.

Exploratory sessions find the other kind: the second tab that goes stale, the back button after checkout, the invite accepted by an account that already exists. Nobody writes those cases in advance, because writing them requires having already had the idea.

Where it fits

It does not replace the regression suite, and the suite does not replace it. The suite proves that what worked last month still works. A session goes looking for what never worked and was never checked.

We book them against every meaningful feature before release, and the notes ship with the report. How we work shows what one of those write-ups looks like on a real engagement.