I’ve recently been taken aback by some of the things that people have said or written about exploratory testing.

First there was this blog post that says of prep time: “And you would see the exploratory test team sitting idle, because there is no software to explore.” The post continues “In a less dishonest comparison, I’m sure the exploratory team would find something useful to do”. Damn right, and I’m glad the author added that: there is a persistent myth that exploratory testing is unplanned testing. Whilst ET can perform admirably with little or no advanced planning, it can benefit from the opportunity to do so. Every time that I’ve mobilized ET on a project where I’ve had test prep time, I’ve used that time to maximum effect: exploring the context, learning from my stakeholders just what they hoped to get out of the software, absorbing every scrap of information I could get hold of about what the software was meant to do, creating models to describe its behavior, figuring out lists of what to test and how– all with the goal of having a rich a set of test ideas for when something executable arrived. Exploratory testing is not unplanned testing, it simply implies that you accept that what you learn will change the plan.

Next, there was rereading Copeland’s A Practitioner’s Guide to Software Test Design. Copeland claims that ET has no power to prevent bugs whereas scripted testing does; the notion of testing the test basis through test design. The former is true of any testing that has the testers showing up on the same day the code does, but –again- given the opportunity of prep time there is absolutely no reason why such prevention cannot be part of an exploratory approach. Asking questions, seeking clarity and building understanding all have a remarkable power to expose ambiguity and contradiction. ET does not preclude this. An exploratory approach can provide prevention.

Finally there was Rex Black’s recent webinar on test strategies (which I found interesting, but that’s a post for another day). Without explicitly referring to exploratory testing, Black positions ET as being one of several “reactive” test strategies. Now, the term reactive could be taken to have negative connotations, but let’s disregard the realm of management speak that defines the opposite of reactive as proactive and think in terms of plain English. You know? The opposites of reactive include unreactive and unresponsive. I can live with that: ET is reactive in exactly the same way that a corpse isn’t. Anyone else getting an image of moldy dead test scripts? Then there’s the idea that I will know when I am employing a “reactive strategy” because I will be applying my experience rather than a testing technique such as domain testing etc. When did techniques and experience become mutually exclusive? It seems that whenever I’ve applied formal testing techniques during a test session that I wasn’t doing ET at all…silly me. An exploratory approach may be reactive (and that is a good thing), but it does not preclude any test technique.