We’ve written about a number of different types of software testing in the past, from functional testing, black & white box testing, smoke testing, pair testing and more. Many of these testing methods have rigid structures and rules, and a lot of planning and preparation go into them. Most testing involves following a script (a test case) and comparing expected results to actual results. Exploratory testing is different though.

Exploratory testing

Exploratory testing allows the tester a sense of freedom. It is a hands-on approach that simultaneously involves discovering, investigating, and learning. This type of testing maximizes test execution and minimizes planning.

Many of us have probably conducted exploratory testing without even knowing it. For example, when we’re running a scripted test and something unexpected or new comes up, it’s almost natural to switch to an “exploratory” mode.

Characteristics of Exploratory Testing

Less Planning, More Testing

Exploratory testing focuses on executing the tests rather than designing them. In contrast, scripted testing involves a lot of preparation, planning, writing etc. With exploratory testing, the test design phase and test execution phase happen in parallel. There are no scripts or test cases to follow. Rather than following a set of scripts, the tester must decide in the moment what test should be ran next.

Scientific Thinking

Exploratory testing requires the tester to think cognitively. Since no scripts are involved, you really need to be aware of what’s going on and you need to ask the right questions. This is what drives exploratory testing. What happens if I do this? Why does that happen? Answers to each question guide the evolution of the test. You are essentially “exploring” the ins and outs of the software application.

It’s Fun

Exploratory testing is an adventure, and adventures are fun! This approach to testing empowers the tester to steer the direction of the test and promotes a creative way of thinking. With this type of testing, we leave the rules, formal structure, and documentation behind and use our instinct to drive the test.

How to Do it

You don’t want to simply jump into a random part of the application and start testing – you need a purpose and some sort of goal, and you must be diligent. Don’t just verify that something’s working, think of different situations that could cause it to not work.

Test from different angles and from different perspectives. Test performance, security, usability – you may bounce back and forth but that’s expected. Remember, you’re essentially designing the tests at the same time you’re conducting them.

Advantages of Exploratory Testing

Sometimes there isn’t enough time to write a test plan and a set of test cases prior to testing… you just need to get in there and test. Exploratory testing is useful when rapid feedback is required. You also might find it useful for when you’re unsure of which sequence to test things. The process of exploratory testing will “teach” you what to test next.

Most of us have probably conducted exploratory testing when bugs are found. When we find bugs, we typically don’t sit down and right a set of test cases on how to test the bug, we usually just test it. This approach to testing helps us identify the scope and severity of the bug quickly. But there are risks in exploratory testing too.

Disadvantages of Exploratory Testing

There’s often no true record of what’s been tested with exploratory testing. This makes it difficult to measure test coverage and provide the confidence that enough testing has been done. It’s also possible to overlook bugs when testing “on the fly” like this. A pre-defined set of test cases often helps ensure proper test coverage.

Closing Thoughts

Exploratory testing is the “natural” way to test… as software testers, we naturally do this to an extent already, even if we are following scripts. The main advantage of this type of testing is the time you save by combining the test design phase with the test execution phase. The risk here is that less time is put into the test design phase, which can lead to bugs slipping through the cracks due to a lack of test coverage.