Software development is a complex adventure – exploratory testing is a learning journey towards its performance.
Software development is a complex endeavor, so you don’t know about some effects until you see them. These unknown unknowns are a critical risk in almost every product development (ad)venture.
A powerful yet lightweight technique to cope with unknown unknowns is exploratory testing. This approach brings light to the dark corners of missed and misunderstood requirements and helps finding the bugs nobody ever has thought of.
Exploratory testing is a continuous process of experimentation with the software under test, where small experiments are designed and carried out in order to learn about the system and its behavior. The outcomes of the experiment are fed back as ideas for new experiments to continue the learning process.
At first sight, exploratory testing seems like a rather planless approach, since you start with not much more than a timebox and a goal. In practice, however, it is a very disciplined way of testing software. Because new insights are gained through a structured and deliberate step-by-step exploration of the system.
Exploratory testing can be used throughout the whole development process, as soon as some part of the system is finished. There is no need to wait for a fully developed and integrated system – the earlier the feedback is shared and discussed with the rest of the team the better.
Exploratory testing is a cycle of learning, designing, executing and analysing. The first step is to think about what should be tested and which approach is useful to find the desired information. Afterwards a small experiment (or test case) is designed and almost at the same time executed. The observed results are finally analysed and interpreted. Based on this analysis the next cycle is initiated.
To not lose track of the testing effort, it is a good practice to prepare and timebox the test session. The goal for the session and the testing ideas are documented in a light-weight testing charter, which is also used for documentation during the testing effort. As a timebox a duration from 30 to 120 minutes is recommended.
After finishing the test session it is a good idea to share the gained insights with the rest of the team to give feedback and foster communication about the system and its quality.
So much for the theory. In practice, the most difficult part is to find the right point to start from. Where can you find ideas on how to start in a focused way?
The main sources for testing ideas in exploratory testing are the intuition and experience of the tester. But there are possibilities to cheat or better said: to find inspiration.
One of the most used approaches to exploratory testing are tours. You find them on the internet in hundreds of flavors. Using a tour for software testing is a bit like a city trip - there is a basic theme or plan for strolling around, but it can change in case something interesting or unexpected happens.
Another widely used approach is changing perspective by identifying with a possible user of the system. This technique, borrowed from product development, is called persona method and solely the invention of realistic personas is fun.
In case the main goal is finding bugs, a good source testing ideas are failure taxonomies. Basically registers of failure sources and their symptoms.
And there are literally dozens of mnemonics that represent heuristics for the use in testing.
Intrigued by this short blog on exploratory testing? Why not starting directly with a guidebook tour through your system? Just take the user manual and try out, what happens if you follow it by the word - good luck and have fun!
In case you want to first learn more about the method and practice it in a group with the help of an experienced exploratory tester, I invite you to take part in my session on exploratory testing which I’ll host from time to time at trendig’s techtalk practinar! For more information, please visit the Exploratory Testing Practinar page.
trendig
