Exploratory testing is a test-execution approach that is very popular. Especially for agile teams. It has many advantages like, for example:
- Less preparation is needed, and you can start right away.
- Find essential bugs in any stage of your software development lifecycle in a short amount of time.
- Expand your horizon, use your creativity, personal experience, and intuition.
Exploratory testing is much more fun and intellectually stimulating for the tester than the (sometimes “boring”) repetitive execution of scripted tests and, thus, a welcome break from the tester’s everyday life.
But what is precisely the fun of exploratory testing? Let’s take a closer look at that.
Exploratory testing often has the taste of a game. You can organize the test session as a bug hunt and reward the participants with prizes or certificates, which you can hand over in an award ceremony after the test session. The testers can also slip into distinct roles and test the product from that role. Who didn’t like role-playing as a child? With exploratory testing, you are taken back to this time!
Further essential points are collaboration and communication. Think again of a bug hunt. Often all participants are sitting together in one room and talk with each other about what they have discovered. You look over someone’s shoulder, to support his work or to get inspiration for yours. Through exploratory testing, you also can work with new exciting people with whom you usually don’t work. Experts, stakeholders, or end-users can easily be included, and testers can benefit from their experience.
In theory, it sounds like fun – and for the testers, it is. But practice looks somewhat different. Think of the person who has to prepare and, afterward, evaluate the exploratory test session. Experience tells us that this person has a key role in the process. For that person, it is sometimes no fun at all!
I have mentioned above that an exploratory test session needs less preparation. You don’t need a detailed test specification, only a mission – the overall goal of the test session – and charters with starting points for the exploratory test session. Problem: how to provide that information for all participants that it is available during the test session? Unfortunately, it is also not that easy for everybody to participate in a test session in one room. Either because of the current situation due to Covid-19 or because they are spread over various locations or even other countries. How can the organizer get everyone together? Finally, we look at the organizer’s work that needs to be done after an exploratory test session. The poor one has to gather all bugs and issues found during the test session to do the debriefing. Even if all participants have recorded their results in text documents, the organizer has to combine and evaluate the numerous individual documents and then define the further procedure.
If exploratory testing, on the one hand, is a creative, efficient, flexible, fast, collaborative, and rewarding testing method for the testers, but on the other hand, a punishment for the organizer, then this method would probably be doomed to failure in the long run. But, of course, this is not the case!
In my talk at the developer week (Tuesday, November 3rd, 5 p.m., Room Istanbul), I will answer all the open questions outlined in this blog post. And I will reveal how we have managed with appropriate tool support and the right mindset within our teams that exploratory testing became a permanent component of our test strategy as well as how it became fun for all people involved!
But I’ll tell you one more thing: the tool that brings us fun with exploratory testing is TestBench. The basic license is free of charge. Why don’t you try out an exploratory test and give us feedback at the Developer Week!