Exploratory testing is an approach to software testing (unscripted and unrehearsed) whose main feature is that learning, design and execution of the tests are performed simultaneously.

The ‘Exploratory testing’ idea, introduced by Cem Kaner, refers to execute the tests while we think about them, without spending time making or explaining them, relying on the tester’s instincts.

This depends greatly on the skills of the tester since he/she is given freedom and responsibility for optimizing (and managing) the quality of his/her work. It is all based on the experience, the overall knowledge and the motivation/intuition of the tester. The success or failure will depend on what happens in the mind of the tester.

Testers design their tests as they go. They change the tests continuously based on everything they’ve learned so far, including the test they just did, to gain test value.

“Exploratory Testing is not a test phase. It’s a test approach that should be performed in parallel with all test activities in all test phases.” Most critical problems can’t be found without performing exploratory tests.

When to use exploratory testing?

Whenever testers don’t have the product specifications or the requirements are not complete, this kind of testing is the only choice. A little knowledge of what the application does is enough to start.

Another good opportunity to take advantage of exploratory testing is when the product is in full development or still in alpha phase because a lot of changes are made for each minor version and improvement. By using this testing approach, testers may detect important bugs and issues during the testing execution that cannot be found during normal scripted tests.

Planning strategies

There are some ways to organize and structure the exploratory testing process. We could mention these ones among others:

Session-Based Test Management (SBTM): Introduced by the Bach brothers, James and Jon, the Session-Based Test is a way of “structuring” a little the Exploratory test; “structuring” means we have a set of ideas for what we will test and how it will be reported. It is a commitment to complete a task. For example, it could be to separate the main functions into different sessions or to group similar functions like a menu. The session lasts between 45 minutes and several hours and it should be done uninterruptedly. At the end of a session the tester must make a report of the session, indicating the relevant information picked up.

Thread-Based Test Management (TBTM): It is a strategy that refers to a test idea. It’s an activity-based approach. Unlike Session-Based, Thread-Based testing is not time-boxed but it is a generalization of SBTM and it focuses on “doing” and not “getting done”. Here, activities change over time. Therefore, they can be interrupted and resumed, so we should use TBTM when environment is too chaotic.

xBTM: It is a new strategy, introduced by Michael Albrecht, AddQ Consulting, and Christin Wiedemann in 2011. It combines Session-Based Test Management (SBTM) and Thread-Based Test Management (TBTM).

Summarizing, it’s important to remember exploratory testing “is a style of software testing that emphasizes the personal freedom and responsibility of the tester, by treating test-related learning, test design and test result interpretation as mutually supportive activities that run in parallel throughout the project”. It can be very structured and thoroughly documented (either by using SBTM, TBMT or xBTM strategies).  Use SBTM whenever possible and use TBTM when environment is too hectic. If necessary, you could start by making a mind maps with function areas and test techniques. They are great for visualization and collaboration.


Although there is no way to automate the exploratory testing process without killing the purpose of it, we have many tools that help us to make it easier.

Useful links