When a team starts shipping more code per week, the first thing that breaks is not the build. It is the assumption that someone has looked at the product.
Suites verify, testers investigate
An automated test asserts a behaviour somebody already thought of. That is exactly what you want for regressions and exactly what you do not get from it: discovery. Exploratory testing is a different activity — form a hypothesis about where the product is weak, go and look, follow the anomaly.
The faster code lands, the more unthought-of behaviour exists, and the more that second activity pays.
How we run a session
- A charter: one sentence about what we are investigating, time-boxed to 60–90 minutes.
- Real data, or a copy of it, never a tidy fixture.
- Notes as we go: what we tried, what surprised us, what we did not get to.
- Anything reproducible becomes a bug; anything surprising but unreproducible becomes a note for the next session.
Where the bugs actually are
In our own log for last year, the majority of exploratory findings clustered in four places: state after an interrupted flow, permissions on the second account, anything involving time zones or DST, and the second page of every list.
None of those are hard to test. They are just rarely specified, so they are rarely covered by a suite.
A test suite is a memory of past failures. Exploratory testing is how you find the next one.
Using models without dulling the instinct
We use models to generate variations — malformed payloads, boundary values, alternate orderings — and to summarise session notes into reproducible steps. We do not use them to decide what is worth investigating. That judgement is the job.