An Exploration of Exploratory Testing
Exploratory testing is one of the most widely known but poorly understood practices in the software testing community. The term suggests that exploratory testing is a special testing activity, but in reality, all true testing is exploratory in nature.
The term "exploratory testing" is essentially redundant. "Exploratory" simply means "for the purpose of discovery." "Testing," as Cem Kaner defined it, is an empirical technical evaluation of our products on behalf of stakeholders to discover the type of quality-related information those stakeholders are looking for.
You could argue that the term "exploratory" gives the term "testing" a purpose. However, this doesn’t make much sense, because that would imply that "testing" without the term "exploratory" lacks a purpose. That’s nonsense.
So, testing is a search for quality-related information in its most general form. We search for this information to close the gap between what we know about our products and what we don't know about them. The main reason we want to close this knowledge gap is to reveal risks in our products—that's the type of quality-related information we are mainly looking for in testing. A risk is anything that might threaten the value of our products to the people they matter to—essentially, the stakeholders. In short, a risk is a problem that might manifest itself.
Through testing we collect quality-related information about our products to enable other people (e.g., product owners) to make decisions (e.g., shipping decisions). Therefore, the goal is information, not automation—and this search for information is undeniably a rich and open-ended intellectual activity because it requires many different human activities, such as questioning, studying, modeling, exploration, experimentation, making inferences, and so on.
Therefore, this search via testing cannot be encapsulated into discrete procedural units called test cases, considering a test case is just one particular instance of a test. A test is simply a question you ask your product, and tests are executed to gain quality-related information about your product. This implies that a test case is not a test in the same way a recipe is not cooking. Likewise, the number of recipes you have doesn’t reveal anything about your cooking skills, an itinerary is not a trip, a sheet of music is not a musical performance, and a file of PowerPoint slides is not a conference talk. As Michael Bolton says, the former things are artifacts, and the latter things are human performances.
Exploratory testing is a human performance, not an act of artifact creation. The artifacts, such as test cases, may be produced before, during, or after the act of testing.
Therefore, we can conclude that a tester can test without test cases, and that is exactly what a tester does during exploratory testing.
Ingo Philipp is presenting the session Rediscover Exploratory Testing at STARWEST 2018, September 30–October 5 in Anaheim, California.
I want to make it clear that this article only summarizes a tiny little bit of the brilliant thoughts of James Bach, Michael Bolton, and Cem Kaner. I want to use this opportunity to say "THANK YOU EVER SO MUCH!" to these bright minds. You guys are true thought leaders, since you constantly express thoughts that shake up the status quo of software testing. You know the way, you go the way, and you show the way of professional testing. That's why I am so grateful for all your hard work. Thanks, Ingo.