Your guide to exploratory testing

TWS Avatar

Karolina, Senior Quality Engineer

Last year, I discovered that many of my software development teammates were unsure about exploratory testing – what’s involved in it and how to perform it. To help them understand its value, I developed some training materials that explained the concept more clearly and, after sharing this training internally in the company, I decided to make it accessible to an even wider audience. In this article, I’ll share with you some ideas on how you can introduce exploratory testing into your work too.

Did you know? The first definition of exploratory testing was proposed in 1984 by Cem Kaner, Professor of Software Engineering at Florida Institute of Technology. It is still valid today.

Kaner states that exploration is…

a style of software testing that emphasises the personal freedom and responsibility of the individual tester to continually optimise the quality of their work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”

Exploration is a helpful technique which can be used in wide variety of jobs and their processes. It’s not always focused only on the user-facing components, it could be focused on back-end testing, or  testing UI with Inspector or logs open. Using this exploratory testing method, we can learn more about our software, identify improvements and find defects that would not be so easily discovered if different testing methods were being used.

Exploration can be done at any moment of the process, for example on a local machine when coding is ready or even in the early meetings where we can start to think in edge case scenarios, explore possibilities, and maybe come up with ways to prevent defects from happening. You could even consider exploration when carrying out a code review of your colleague’s code when trying to find defects and improvements.

How does exploratory testing work?

The best way to perform an exploratory testing session is to use the agile ‘timeboxing’ technique, which allocates a fixed maximum time to a certain activity. This ensures that we don’t go off on tangents and use the time to focus only on the specific area we’ve decided to test.

In exploration, we test as we feel in the given moment, taking into account met circumstances without the need for documentation. It requires minimum preparation beforehand, but having in-depth knowledge about the product is a big plus, although this technique can also be used as a way to learn about the product we test.

Before you start using exploratory testing

Before beginning your exploratory testing, it’s important to know what or who is your go-to for help if you find any issues, or if you’re unsure whether a certain behaviour is expected.

It could be anything or anybody – code, an inspector tool, a product owner, a workmate, logs, or QA.

Now, let’s say we have a new sign-up feature to be tested…

To explain how to perform possible processes for an exploratory testing scenario, let’s go through some small preparations, starting with a mind map, drawing up testing charters and finishing it all with pair testing.

Mind mapping

Creating a mind map can tell us which areas of a given feature need to be tested, and it can also help us at the end of session when reviewing actual testing coverage. It’s a great way to visualise your main idea that sits the centre of the map with related topics around it. For example:


We can then use our mind map to create test charters. Charters are like objectives, and they’re used to help us understand where to explore, what resources are available, and what information to discover within your test subject. There are a few ways to approach them, but here are a few examples:

  • Explore the sign-up process with invalid data to discover potential issues with error messages.
  • Explore the sign-up process with mobile devices to discover potential issues with the UI compliance.

We should remember not to go into too much detail, otherwise our area of exploration could balloon into an entire test case.

Once the test charters are decided, we can agree on timeboxing parameters and start testing!

Remember to take notes

If we spot any issues during our exploration, we should note them for investigation either during or straight after the session in case we’re unable to reproduce what we’ve seen. Taking notes can also help us provide enough detail to either fix the issues we’ve found or implement improvements. Your notes might look something like this:

  • Charter: Explore the sign-up functionality with invalid data to discover potential problems with error messages.
  • Time: 60 minutes
  • Notes:
    • Tried to sign up with a user name containing unsupported characters. XYS error appeared. Expected behaviour.
    • Tried to sign up with an unsupported user email address and it has proceeded. Unexpected behaviour. Investigate later.

Testing as a team

Sometimes it’s more helpful to have more than one pair of eyes to support your exploratory testing and create the ideal environment to learn about your product and its features. This provides us with structure, accountability and creativity.

Pair testing puts two colleagues together to accomplish the same goals whereas mob testing requires a few people testing at the same time. Traditional pairing is great way to learn about the project, as one of the pair the navigator performing the test and the other is watching and taking notes.

Strong style pairing is helpful style that you could consider, as it includes one navigator giving one operator commands to perform. Usually, the pair switches the roles in the middle of testing to increase the engagements during the activity.

To start with pair testing, write down some ideas for areas you might know well and those you aren’t as familiar with. Pair up with a colleague who can help you learn about the missing areas, ideally one you can help by looping them in on everything you know about the app yourself to add the bonus of collaboration and improve your teamwork at the same time.

I recommend trying out these approaches if you haven’t already, especially during the Software Development Life Cycle (SDLC) in addition to other daily manual or automated tasks.

For more details, I recommend the book Explore It! Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson.

And don’t forget, exploratory testing is all about collaboration and teamwork – so have fun!

Share this article

Next Articles

Words matter: Using LGBTQ+ inclusive language at work
June 17, 2022

Words matter: Using LGBTQ+ inclusive language at work

When looking to foster a more inclusive work environment where people can be free to be themselves and thrive, we all need to make sure we’re contributing. This Pride Month, we’re placing a focus on LGBTQ+ inclusive language at work, and discussing why we all have a responsibility to appreciate it and use it correctly.
Empowering insights: A data analyst's journey at J on the Beach
June 12, 2022

Empowering insights: A data analyst's journey at J on the Beach

Our data analyst Marta Lahoya visited the J on the Beach conference in Málaga. These are her key takeaways.

Escrito en inglés.
Why should engineers choose Berlin and blockchain?
May 27, 2022

Why should engineers choose Berlin and blockchain?

In 1962, famed British science fiction author Arthur C. Clarke published an essay containing his ‘three laws.’ The third and most famous of these states: any sufficiently advanced technology is indistinguishable from magic.