What is Exploratory Testing

A practitioner explanation of Exploratory Testing. We also cover some of the myths and misinformation statements around Exploratory Testing.

Exploratory Testing is an approach that you can improve over time, and with practice. Use the applications and pages on this site to develop your Exploratory Testing skills.

What is Exploratory Testing?

Exploratory Testing is the term used to describe an approach to testing which stresses the need for autonomy, learning, investigation and experimentation when testing.

  • Autonomy
    • The tester has the freedom to choose what to do next, rather than it being defined in advanced. This creates an environment where the tester can learn and discover new information about the system under test.
  • Learning
    • When testing software we are trying to work with the reality of the software, rather than our beliefs about the software. Constant learning, to expand our model and understanding of the Software is necessary, this leads to new ideas, new experiments and evidence based information as an output.
  • Investigation
    • Rather than a plan which provides a set of procedures for the tester to follow. A plan for Exploratory Testing describes the areas for investigation, and the type of information that we hope to find. One aim of Exploratory Testing is to keep investigating new areas of the system, or new ways to investigate the system.
  • Experimentation
    • Exploratory Testing requires experimentation with the Software Under Test to uncover new insights and falsify existing assumptions or beliefs about the Software.

Exploratory Testing is a highly disciplined and skilled approach to testing.

The tester has to take responsibility for:

  • planning their actions
  • documenting their thoughts and actions
  • observing the system in action
  • gathering evidence
  • making decisions about replanning and data
  • investigating the results in detail or relying on surface observations
  • communicating the results of their testing

This might seem like Exploratory Testing requires a highly skilled tester. And it’s true that a highly skilled tester will more likely be able to perform Exploratory Testing well. But Exploratory Testing is also an excellent way of becoming a Highly Skilled Tester.

You can use many of the test pages, challenges and applications on this site to practice Exploratory Testing. There are usually hints in the Instructions for exercises to perform.

Remember one of the skills of Exploratory Testing is coming up with new exercises. So as you improve your Exploratory Testing Skillset, you’ll be able to use any of the pages, apps or challenges and create your own Exploratory Testing Exercises.

Is all Testing Exploratory?

When the aim of the Software Testing Process is to uncover new information about the Software then all testing performed will have some element of exploration.

Some test approaches emphasis the following of a script. The aim of this process is coverage, rather than new information. New information is a side-effect of achieving coverage.

New information can be found when following a script:

  • when the person following the script is unable to take the next step due to an issue,
  • the person following the script spots something unexpected when performing a step in the script,
  • the script is written at a high-level and the person following the script interprets the instructions such that they follow a path, or use data, that hasn’t been used before.

The last example in the list hints at autonomy and experimentation. The script was open to interpretation, so the person following it had autonomy in how they interpret it. The interpretation might have led to a new path, or a new way of triggering a feature (e.g. using keyboard rather than mouse), or data that had not been tried before. The variation, although not thought of as an experiment, was accidentally experimental and led to new information.

Can Exploratory Testing be Automated?

Automating is an important and useful approach for achieving coverage. Automated Execution can often take the place of a human following a script. Automating and coverage, is an important aspect for confirming beliefs and assumptions about the Software.

Automation can not take yet take the place of someone operating with autonomy and experimenting with the system, although this is something that some people believe AI has the possibility to help with.

The emphasis for Testing is on new information (which requires experimentation), rather than confirming what we already know (which can be achieved by following a scripted procedure and automating).

Exploratory Testing uses tools to help the tester, rather than automate and replace the tester.

Is Exploratory Testing unplanned?

Exploratory Testing is always approached with some sort of plan or idea. Even if the plan is “I’ll randomly poke about and see what I learn.”.

Exploratory Testing requires ‘just enough’ planning.

Planning to ensure that:

  • the tester has the training and skills required to test adequately.
  • the tester has the knowledge of the functionality about to be tested such that they can evaluate it and identify issues.
  • the testing meets the current needs of the project and will provide information of value.
  • the testing doesn’t repeat testing that has been performed before and would therefore be less likely to reveal new information.
  • the tester can explain “Why” they are about to explore a certain part of the application.
  • the tester has the tools they need to observe the system during testing to spot issues and interrogate the system to investigate the results and impact of their testing.
  • the tester is not about to waste their, or the project’s time.

An important aspect of Exploratory Testing is that the plan has flexibility.

If, during the testing, the tester observes behaviour that is unexpected, then they have the flexibility to choose to investigate this behaviour in more detail, they are not forced to ‘stick to the plan’ and ignore new opportunity to learn new information.

When performing Exploratory Testing, the tester will usually write down their ‘plan’ as a list of aims and objectives. This is plan is often called a ‘Charter’.

Is Exploratory Testing Repeatable?

One criticism made against Exploratory Testing is that it is not repeatable.

This is obviously not true. When performing testing, a tester will gather evidence, and this requires making notes about what they are doing, thinking and decisions they have made. This record of the testing process could obviously be used by someone else to repeat the same actions.

A question should be asked though: “Do we want the testing to be repeated?”.

We want the ability to recreate any observations made, particularly when an issue or risk has been identified. This need can be supported by building a set of repeatable performing steps, data and state required to setup conditions. This would be done during the investigative exploratory process.

The need for repeatability might imply a need to assess coverage achieved by the testing, and not just this single testing activity, but all the Exploratory Testing sessions put together.

This need to assess coverage can also be met during Exploratory Testing by making notes of the data, paths, decisions and actions taken during the testing, and combining them into a coverage model.

Exploratory Testing does not imply a lack of rigour, planning, management or assessment of the testing process.

Is Exploratory Testing All About the User?

Exploratory Testing is often described as:

  • focused on the User Experience,
  • testing like a user would.

Describing Exploratory Testing in this way limits the scope of Exploratory Testing.

We may choose to test software completely unlike a user would, because we need to investigate states and functional integration that a user would not be likely to use, but because they are possible, there might be more risk if they are used.

  • e.g. if we only tested software like a user would:
    • we would never test the way a hacker would, and would never find security issues.
    • we would never interact with the software the way a bot would, and would never find issues that might be triggered by crawlers or AI Agents.

We test the software, the way it is required to be tested for the scope and information we are pursuing.

Exploratory Testing often requires more detailed tooling to: see HTTP requests, manipulate HTTP requests, view the database directly - none of this is required for ‘user’ testing.

This does not mean we do not test from User’s perspective. We do. We also go far beyond this.

Can I use Exploratory Testing when the System is unstable?

Yes of course. It is a common misconception that Exploratory Testing should only be used when the system is stable.

What other type of testing should be used when the system is unstable? Clearly you can’t adopt a scripted approach to software testing because the system is too unstable to write repeatable scripts, or follow them to any useful extent.

The question should really be: “Is the stable enough that the information we receive from testing can be acted upon?”

If the system is unstable and, during your testing you find an issue, but the response to the issue is “Well of course, we expect issues like that because the system is unstable and we will fix it.” Then perhaps you should not be testing at all yet.

Is Exploratory Testing Undocumented?

No. This is another common misconception.

Exploratory Testing is often more documented than ‘Scripted Testing’.

When someone is following a script, the output documentation is often a set of ’ticks’ next to each step, with no record of the observations made during the testing so you don’t really know if the script was followed or if any observable issues were actually missed.

When someone is performing Exploratory Testing they are documenting:

  • what they have done
  • why they did it
  • what they observed
  • what data they used
  • what questions they have
  • what risks they have identified
  • what new test ideas they have thought of
  • what issues they have seen (with evidence, and how to replicate)
  • etc.

The output of Exploratory Testing is usually more documentation evidencing the testing than supports Scripted Testing.

The documentation is not created up front, like scripted testing, but instead created during the testing.

This actually helps keep the tester’s attention on the testing and observing the system.

One issue with following a script is that the person often focuses more on the script, rather than what is happening as they use the software.

Examples of Exploratory Testing

We’ve included some example videos below covering Exploratory Testing.

Blog Posts On Exploratory Testing