I was wrong about exploratory testing, are you?

After a week with James Bach on his RST Explored course, I left with a greater understanding of testing — but also with a few of my own testing illusions completely destroyed. One of the main misconceptions I had about exploratory testing was that it was even a “thing”. I thought it was an approach, or a method, or some specific way of thinking about testing. After spending time with James, I realised that isn’t the case at all.

He started with the quote:

“All testing is exploratory… to some extent.”

I’ve heard other people talk about this idea before, but I never fully understood what it meant. What James meant is that testing is about making choices. A tester chooses a path by making decisions, moment by moment. That, he argues, is exploration.

Exploration is defined as “travel through (an unfamiliar area) in order to learn about it” — even if it doesn’t feel like we’re actually travelling anywhere. Another Oxford definition of explore is “inquire into or discuss (a subject) in detail”, which also perfectly describes what we do when we test.

Exploring and travelling are actually very useful ways to think about testing, especially when you look at the vocabulary we already use in our work. One that immediately comes to mind is mapping — data mapping, requirement mapping, mind maps. These help guide our exploration and enable us to make better choices.

There are plenty of other examples too:

• Path: file paths, URL paths, navigation paths
• Accessibility: are you able to access this space? are others?
• Authorization: are you allowed in this space — physically or digitally?
• Boundary: what happens if I cross this line?

We also talk about buffers, walkthroughs, trees, user journeys, and so on. When we test, we are moving through space with our minds.

James’ latest definition of exploratory testing is:

“Exploratory testing is testing by someone who possesses agency and is therefore accountable for that work.”

Notice that it doesn’t mention an approach to testing — because it isn’t an approach. It is testing. Many other sources describe exploratory testing as if it’s a distinct style or technique, separate from other forms of testing. That’s not what James intended (hence his claim that ISTQB vandalized his definition).

In my own experience, I’ve encountered people who use exploratory testing to mean ad-hoc testing or randomly clicking around. I’ve often jumped in to correct that definition, saying that what they’re describing isn’t ET. But after reflecting on this, I realised that it actually is part of ET — just a very small part. If all testing is exploratory, then even that behaviour sits somewhere within it.

There’s also the idea that James Bach believes “all testing is scripted… to some extent” as well. Exploration grows the explorer; scripts constrain the follower. When you explore, you aim to learn. Scripts help keep you honest and focused. By the time your testing becomes more scripted, you’ve probably learned a great deal about the product and are now aiming to confirm or verify specific behaviours.

That realisation alone changed how I think about testing — and about exploratory testing in particular.