Exploratory

The question: what did none of us think to write a test for?

Every automated test encodes an expectation someone already had. That is its strength — it is repeatable — and its ceiling: a suite can only fail in ways someone anticipated. Exploratory testing is the deliberate search outside that set, and it is the reason the typology cannot be replaced by more automation.

It is not manual testing. Manual testing is following a script a person wrote, by hand — which is automation performed by the wrong machine, and should be automated or deleted. Exploratory testing is simultaneous learning, design and execution: what you find in the first ten minutes decides what you try in the next ten.

Chartered, time-boxed, recorded

Unstructured “have a click around” produces nothing anyone can act on or repeat. The structure is three things, and they are cheap.

A charter — one sentence naming the mission. Explore the discount application on the basket, with combinations of promotional codes and member tiers, to discover cases where the total is wrong. Specific enough to focus, open enough to follow a thread.

A time box — 60 to 90 minutes. Long enough to get past the obvious, short enough that attention holds and that the session is a schedulable unit.

Notes — what was tried, what was observed, what was surprising, what could not be tried and why. The last two are the valuable ones: a surprise is a defect or a documentation gap, and a blocker is usually a testability problem worth fixing.

Where the ideas come from

The skill is generating candidate ways to be wrong. A few heuristics that reliably produce them:

Boundaries. Zero, one, many, maximum, maximum plus one, negative, empty string, whitespace, the longest string the field accepts, an emoji, a right-to- left name, a leap day, a leap second, a DST transition, the last day of a month.

Sequence and interruption. Back button. Double-submit. Two tabs. Refresh mid-flow. Log out in another tab, then continue here. Kill the network halfway through the request and restore it.

Identity and state. A brand-new account, an account with 40,000 orders, an account mid-migration, a deactivated account, a user whose permissions changed during the session.

Following the surprise. The most productive move in the room: when something is slightly odd — a flicker, an extra request, a number that took too long — stop and pull that thread. The bug is rarely where you were looking.

Who does it, and when

Not only testers. A developer exploring a colleague’s feature finds things the author cannot see, because the author is testing the system they intended to build. A support engineer finds what customers will actually do. A product owner finds what the feature does not do.

The one rule: not the person who wrote it, at least not alone.

When: per feature, before it ships, on a deployed candidate with realistic data. And after any production incident, as a charter aimed at the neighbourhood the incident came from — that is where the next one usually is.

What comes out of a session

Defects, with evidence — a recording, the request, the state.

Test ideas. The valuable output. Anything found here that is deterministic and worth checking forever becomes an automated test at the cheapest level that can hold it. The session found it once; the suite keeps it found.

Testability problems. “I could not tell whether the retry happened”, “there is no way to create this state without the database” — these are development work and they compound. See shift-left.

Coverage notes. What was not explored, so that the risk model reflects reality rather than intention.

Why it is not a release gate

It cannot fail a build — it produces findings rather than a verdict, and it is never complete. It informs the go/no-go conversation instead: what was explored, what was found, what was not reached.

A team that makes it a gate quickly reduces it to a checklist, and a checklist is a script, and a script is automation performed by the wrong machine. See the exploratory campaign.

Tooling

Very little, on purpose: a session-notes template, a screen recorder, the browser’s own developer tools, and something to capture requests. The exploratory charter MCP server sketches generating charters from a change set and a risk model — described, not built.