Exploratory testing is mandatory

With the movement to automate everything and bridging the gap between QA Engineers and Developers, the idea of exploratory testing has become a low priority for many teams and organizations. The process for a QA Engineer usually revolves around executing a per-determined set of test cases. If they want to go further, they do a final walk-through of the test cases before they sign off on a build. This could be manual or automated, it’s not relevant to this discussion.

Executing  tests as a script is useful as it ensures we have covered the basic and non-basic flows. However, it does not guarantee good coverage. It also limits our creativity for finding bugs. Supplementing test scripts with exploratory testing enables us to uncover paths and scenarios we might have missed in our script. Testing those extra edge-cases makes for a higher quality product or service. That extra human touch makes a difference.

Exploratory testing can be done by us or out-sourced. If we have the time, we should do both. If we ourselves test, we benefit from knowing the weaknesses of the code and save time with the back-and-forth with an out-sourced group. An out-sourced group is useful as they come from an unbiased perspective. Their imaginations are not cluttered or limited with what was already tested. They also help uncover other types of issues, such as non-ideal UX flows and interactions.

You can build exploratory testing into your workflow easily. After you test a feature or a code change, add a small amount of time for exploratory testing at the end. You could add it while the scripts are being executed. You could also add it after you’ve tested everything, although this is the non-ideal practice. Wherever you add it, it’s definitely better than not having it at all.