I’m pretty sure you have heard things about Exploratory Testing, you have most probably heard about how awesome it is. (Yes! This is the secret weapon!) And you may think you know it ALL. You are doing it, your team is doing it, so all should be good, according to the big book of plans you are all covered.
When you say or hear that someone was finding bugs by “just clicking around and found these issues, I did some exploratory testing“, then you can be as certain as death and taxes that it was not exploratory testing.
When you hear from the scrum master/whoever that “let’s do some exploratory testing before the live release just to make sure that everything is fine“, then you can be certain that they have no idea what they are talking about.
So what’s the point of Exploratory Testing? WHY is it great?
There is a psychological background. Let me explain.
An analysis technique has been developed by Joseph Luft and Harrington Ingham to help people understand their relationship with themselves and others. They called it the Johari window.
In this model there are four quadrants:
– open area: known to others as well as self ~ known known
– blind spot: known to others but not known to self ~ known unknown
– hidden area: not known to others but known to you ~ unknown known
– unknown area: not known to anyone ~ unknown unknown
Whenever you hear the “known knowns” concept, they are referring to this model. Many scientific areas have adapted this concept, and if you follow politics, you may have heard this from Rumsfeld in 2002 at a briefing.
And this model can be applied to software development as well.
The known knowns are the requirements that can be covered with automated and manual tests.
The unknown knowns are our assumptions or expectations about the software, like the software performance. By doing performance testing we can make this to known known.
Our blind spots can be covered by raising questions.
Usually, when we are talking about how confident we are in terms of the quality of the software, we mean these, these give us confidence.
Which is not enough. Automated and manual tests alone are not necessarily enough to ensure the software is working correctly and efficiently. So confidence should be raised. How do we do that?
Potential issues are hiding in the Unknown Unknown that can escape to production and cause reputation loss. We can catch issues that live in the Unknown Unknown area and raise confidence by exploration.
And this is where Exploratory Testing comes to the picture.
So WHAT IS Exploratory Testing again?
Exploratory testing is a style of testing in which testers are simultaneously learning about the system while designing and executing tests, using feedback from the last test to inform the next.
It is not ad hoc testing.
How do we explore in general? Just think about it.
When we explore, we know where we want to go and what we want to achieve, we just don’t have an exact plan.
There is one more thing psychological term that can be a good input to understand exploratory testing: Inattentional Blindness
In the end, I can just encourage you to raise your voice whenever you see an article that states exploratory testing as ad-hoc, unstructured testing. No, it is not.
And if someone tells you that those bugs were found during exploratory testing, which was “just clicking around”, you can tell them “good catch, however, they just got lucky”.