Part One: What Is Exploratory Testing and How to Prepare It

One might think that a test management tool like TestBench CS should focus on systematic or scripted testing, test automation, requirement tracking, and hard facts. And it does.

However, in the real world, there is more than that. A test manager responsible for testing a product needs to take thoroughly full advantage of all his team’s capabilities. That includes the creative power of the team members.

With a systematic approach, starting with requirements, epics, or user stories, writing test cases, you rarely achieve that. What you get is other essential things: You know what is tested and what is not. You get a certain test coverage. You get a (more or less reliable) assessment of the quality of the product. You get repeatable regression tests. You get proof of what has been done.

All these things are precious. And that is why we will continue to do systematic testing.

But to really unleash the creative potential of your team members, you need to give them more freedom – and the best way to do this is Exploratory Testing.

What Is Exploratory Testing

Exploratory testing is a test practice – some prefer to name it a “style of testing” – where no test cases are written in advance. Informal test cases are identified while you go. In fact, while any documentation on the test item is undoubtedly valuable, exploratory testing could still be done even without that. If documentation is not available, you use the experience of your testers instead.

That is just supposed to picture how flexible exploratory testing can be. If you are lucky enough to have decent documentation, you will certainly use it.

So, you could argue, instead of using exploratory testing, we should maybe use proper systematic testing. I disagree. I am convinced that a sound test strategy needs to support both systematic testing and exploratory testing. And since TestBench CS is meant to be your platform for software testing, we made sure it supports exploratory testing, too.

There are many flavors of exploratory testing in the world. Our way of doing it is performing exploratory testing sessions. Core elements in an exploratory testing session are the team, the mission, the charters, the timebox, the actual exploring, and the debriefing. Let’s take a closer look at those.

Prepare Your Test Session

  • Team

The team is the most crucial factor in exploratory testing. Team members contribute their time, experience, and above all, their creativity. During the session, each team member explores the system under test (SUT), finds test cases, executes them on the fly, develops assumptions on the right behavior, and logs all findings. While doing this, new ideas for further testing are created based on the so-far gained knowledge.

Choose the team for the Exploratory Test Session.

While we can’t help you select your team, what TestBench can do is help you to communicate with your team. Just use the integrated chat feature to create a chat group for your session. Use this chat group to invite the team and stay in touch before, during, and after the session!

 

  • Mission

When preparing an exploratory test session, the crucial thing is to define the mission and the test charters. The mission is the one thing to rule it all, the one thing to find it… It connects all participants in the Exploratory Testing Session, which sets a global goal, and what helps to make sure that all participants strive for the same objective. Take care that it explains what you are doing, what needs to be in the team’s focus, and why you are setting up this particular Exploratory Testing Session, and why it’s special. Do not use copy and paste to create your mission! If you do, very soon, people realize that it’s always the same and won’t believe it’s worth reading. In TestBench, define your mission in the main view for your Exploratory Test Session. If you do, every participant can, during the session, see and re-visit your mission at any time.

Write down the mission for the Exploratory Test Session.

 

  • Charters

So, beyond the mission, the charters are the other crucial thing in exploratory testing. While the mission describes the general objective, the charters describe specific views, jobs, and tasks covered during exploratory testing. They ensure that your mission is fulfilled and prevent your team members from scurrying around in the same area. Team members may have the freedom to pick charters, ideally choosing those no one else is working on. In TestBench, you can always see how many people are working on which charter.

Define the charters.

Or you assign a charter to a specific person – if someone is simply best suited to handle a charter. Take your time to define charters. Describe them perspective based, or use mnemonics or test tours.

 

  • Timebox

For exploratory testing, a timebox should be neither too big nor too small. Often, 90 minutes up to two hours are recommended. If it’s longer, your concentration may degrade, or you might end up forgetting what you learned in the beginning. If it’s shorter, you may not have enough time to work on the charters adequately. However, you can make a distinction between the personal timebox for each team member and the overall timebox for all team members and the joint session: If they cannot work at the synchronized at the same time, you could allow, e.g., a 24-hour time span in which each team member spends 90 minutes testing.

Set the timebox.

In TestBench, you can plan your Exploratory Test Session by setting a start and end date for all members. Plans can change, so your actual session does not start before you put its status to “Running” – maintaining the length. During the session, every participant can, at any time, see how much time is left for exploring.

See how much time is left.

Now you are ready to explore! Stay tuned for the next blog post with information on the execution of the Exploratory Test Session and the debriefing afterward.


Matthias Daigl

Matthias Daigl studied computer science. He spent most of his professional life as a tester, trainer, and consultant at imbus. For many years, he has been active in various committees, including ISTQB and ISO. Today, he is the Product Owner for TestBench CS and works with three international teams.