Testlio testers spend more than 50% of their time doing exploratory testing, which is the most interesting form, in my opinion.
There are a few main skills a tester needs to succeed with the exploratory method and add value to a project. In no particular order, these are:
- Having experience with the method (to be able to stay on track with the key important areas of a test cycle).
- A technical background, to understand what’s happening and why—and in some cases predict the issue appearing.
- The ability to understand the cause-effect relationship of the testing performed and the result.
- Knowledge of the product’s structure and user flows.
Of all of these, understanding cause and effect is the most valuable.
Imagine this common situation: you are testing a mobile app and doing a sequence of actions. Suddenly the app crashes (or it shows an error or behaves incorrectly), and you don’t know exactly why it crashed.
You try repeating your latest action, but the app doesn’t crash this time. What should you do? The first thing you try to do is recall all of your recent actions with as much detail as possible. Let’s say you remember all of these previous actions, repeat them all, and are able to reproduce the issue. The app crashes again.
But what if those actions amounted to 15 steps? What if these actions included some behavior in the OS or inside another app? Of course, you could submit this issue with all the 15 steps, but that’s bad practice because there is a possibility that as many of 13 of these 15 steps are irrelevant.
Your next goal will be minimizing the number of steps.
How can you do this? If you were to try and repeat the 15 steps while excluding each one in turn, it would take too much time to check all the combinations. To guess would be to risk inaccuracy.
If you have skill number 2 (technical background) and number 3 (the ability to understand cause-effect relationships), you will spend far less time. You will know to exclude the few steps most likely not related to the issue: steps not related to the functionality that caused the crash, steps you already completed that didn’t cause the crash, and so on.
Once you’ve excluded these steps, you can try to reproduce again. If the issue doesn’t reproduce, then you excluded something required for reproduction, so get it back!
If the issue does reproduce, you can continue excluding a few additional steps. The better you understand what’s happening and why, the fewer mistakes you will make and the less time you will need to find the exact sequence.
Combine this understanding together with a technical background and a logic-driven mind, and you will excel at finding issues with exploratory testing. When you add knowledge of the user flows, you will find a lot of customer issues—as many as you have the time to test for.
This post by Max Kolesnikov is part of a new series written by our community of testers.
Want to join our testing community? Email us: email@example.com.