1
Exploratory Testing Explained
v.1.3 4/16/03
James Bach
james@satisfice.com
copyright © 2002-2003, James Bach
Exploratory software testing is a powerful approach, yet widely misunderstood. In some
situations, it can be orders of magnitude more productive than scripted testing. All testers
practice some form of exploratory testing, unless they simply don’t create tests at all. Yet few
of us study this approach, and it doesn't get much respect in our field. This attitude is
beginning to change as companies seek ever more agile and cost effective methods of
developing software.
Among the hardest things to explain is something that everyone already knows. We all know
how to listen, how to read, how to think, and how to tell anecdotes about the events in our
lives. As adults, we do these things everyday. Yet the level of any of these skills, possessed by
the average person, may not be adequate for certain special situations. Psychotherapists must
be expert listeners and lawyers expert readers; research scientists must scour their thinking for
errors and journalists report stories that transcend parlor anecdote.
So it is with exploratory testing (ET): simultaneous learning, test design and test execution.
This is a simple concept. But the fact that it can be described in a sentence can make it seem
like something not worth describing. Its highly situational structure can make it seem, to the
casual observer, that it has no structure at all. That’s why textbooks on software testing, with
few exceptions, either don’t discuss exploratory testing, or discuss it only to dismiss it as an
unworthy practice.
Exploratory testing is also known as ad hoc testing. Unfortunately, ad hoc is too often
synonymous with sloppy and careless work. So, in the early 1990s a group of test
methodologists (now calling themselves the Context-Driven School) began using the term
“exploratory”, instead. With this new terminology, first published by Cem Kaner in his book
Testing Computer Software, the