Exploratory testing

Exploratory testing is simultaneous learning, test design and execution. Instead of working down a list written in advance, a tester forms a question about the product, acts on it, and lets the answer choose the next question. It is disciplined work despite the name. Sessions are timeboxed and given a charter stating which area is under investigation and what is suspected about it, and the tester keeps notes as they go, so the session can be reviewed afterwards by somebody who was not in the room.

It earns its place because a written case can only ever check what its author already suspected. Everything else is found by somebody curious, holding a model of how the system ought to behave and noticing the moment reality disagrees. Commercially this matters most on new features, on anything with an unusual sequence of states, and on integrations where the specification belongs to somebody else. Those are precisely the areas where writing cases first is slowest and least productive, because the product is still changing shape underneath the cases as they are written. It is also the quickest way to build a working mental model of an unfamiliar system, which is why it tends to be the first thing we do on a new engagement.

What a session actually consists of

• A charter naming the area and the risk: which part of the product, and what specifically we suspect might be wrong with it.
• A timebox, usually between half an hour and two hours, so the work has a boundary and can be planned against everything else that needs testing.
• Notes captured while the session runs, recording what was tried, what was observed, and which questions were left open at the end.
• A short debrief, where open questions become either fresh charters or defect reports, and the coverage claim turns into something a release decision can rest on.

Unscripted is not the same as unplanned, and a session leaving no written record is the version of this practice that earned it a bad reputation among managers.