Following a conversation on Twitter about whether exploratory testing is structured there are testers who are confusing adhoc testing for exploratory testing in interviews. When asked if they do exploratory testing they say that they do it and it’s all “clicking around to find bugs”.

That my friends is not exploratory testing, it’s adhoc testing. In this post I’m going to lay out the difference between these two testing styles.

What is adhoc testing?

Adhoc testing is an informal style of testing that’s usually unplanned (in that we don’t plan specific tests) where the tester will try different things to find bugs. This technique is usually seen in bug bashes with the aim being to “try to break the system” through chaotic system use.

What is exploratory testing?

Exploratory testing is a technique we use to learn about what we don’t know about something with the intention of sharing that information to help with making design decisions. We structure this testing to ensure that the information we find is useful and relevant to our team.

What are the differences?

Area	Adhoc testing	Exploratory testing
What is the focus?	Bug hunting	Learning
What can we test?	The end product	Anything
When do we do it?	At the end of the SDLC Bug bashes	Any time
Type of structure?	Opportunistic	Targeted
What is it based off of?	Error guessing Domain knowledge Product knowledge	Risks Heuristics Charters / Missions

What is the focus?

In adhoc testing our aim is usually to find actionable quality information (errors that we can document as bugs). The bugs we find may or may not relate to what is being worked on right now by the team so are documented for fix later. Where testing is unplanned we do not tend to create test notes so it can be hard to know what we have tested or share information 

In exploratory testing our aim is to learn and find out information about the unknown and then share this. The information we find is scoped to be related to what the team is working on now so that it’s meaningful and can help drive decisions. We make test notes on what we explore to aid with sharing knowledge and debriefing so we can easily share what has been tested.

Note: In both adhoc testing and exploratory testing we aim to find quality information. In my experience, we mostly use adhoc testing for bug hunting (like a bug bash) but we can use this style of testing to drive out any quality information.

What can we test (and when do we test)?

Adhoc testing is playing around with something that’s been built to find errors in it. This means we need to have the product built to have something to test against. Because of this adhoc testing happens at the end of the software delivery lifecycle (SDLC).

Exploratory testing is about finding information, this means we’re able to test ideas and don’t need a product to test against. Exploratory testing can help test the concepts of a project, test out acceptance criteria, test designs, code and services or the product. We can push our testing earlier and shorten feedback loops for quality and even prevent bugs before they happen.

Is this testing structured?

In adhoc testing our testing is more opportunistic; we may focus tests in an area at a high level but we do not create test cases or target for information within a set scope. We also don’t create test notes, so we’re not able to share what has been tested or use this to drive learning of the system.

Exploratory testing should be structured to give us a scope and aim of our testing; this ensures that our testing is meaningful and focused on giving our team useful information. An example of doing this is by using test charters, like the style proposed by Elizabeth Hendrickson where we say Explore <target> with <resources> to discover <information> to specify a purpose and scope of the exploration and give structure to our testing. We also take notes from our exploration to support debriefing and sharing information.

What do we base testing off of?

Adhoc tests aren’t formally based on anything, we tend to play with the system and find issues opportunistically. We may use some heuristics to shape where we test such as prior knowledge of the system, bug clustering or error guessing.

In exploratory testing we can use heuristics to shape our testing and frequequently will base our tests from a risk analysis; identifying where problems might arise so we can learn information about whether this is the case. From these risks we can develop test charters (as mentioned above) to guide our testing and keep it focused on finding out specific information.

Exploring the Arctic vs. a Walk around the block

Exploratory testing is an exploration. Just like an expedition to the Arctic we need to plan where we’re going (have a goal) and what we need to take with us (planned resources) to make it a success. We go out and find something new so that we can document it and share that experience with others.

Adhoc testing is more like a walk around the block. You set off for the walk without much of a plan in mind and you might spot something interesting amongst all the same sights you’re familiar with.

There is value in both of these activities, they just are different in that they require different levels of planning and give different outcomes.

Adhoc is not exploratory testing, let’s understand the difference so we can communicate our testing more clearly.

Note: This post was edited for greater clarity after discussions on Twitter.