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:

Charters

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!