It’s been a while since my last blog post, I took a long break for the summer, but I am still not done with figuring out what software testing is.
Just as a quick overview of what happened until now, the basic idea behind all of that was that I am still seeing people being able to recognize what software testing is not, what doesn’t belong to software testing, but when it comes to define testing or describe what software testing is, they remain silent.
So, we made a quick run through what software testing is not, if you didn’t have the chance to take a look at the series I encourage you to start here: Software testing is not…
And again, I am not trying to redefine anything, I am not trying to make it into the software testing textbooks, although there isn’t any, my sole purpose is to try to make sense of these to myself. If it works for you too or you agree with me, it is just a bonus. So here’s what I figured out about software testing and what it is, for me:
So, here we go with #1:
Software testing is… exploratory by nature.
I must admit that, since I started working as a tester, I always encountered that concept of exploratory testing, mainly in the sense of “mingling around testing” or freestyle testing or non-reliable, but still useful sort of testing, sometimes. It was year ago or year and a half when I started to dig deeper in ET and found what its true nature is, in fact.
Unfortunately the misunderstanding of exploratory testing, being a technique, being unreliable, chaotic, not organized is still present.
The truth is, exploratory testing is not a technique or a method of testing, in fact, exploration is one of the core abilities that testing uses in order to achieve its goals.
All testing is exploratory.
And it’s true, in its nature all testing is exploratory. Testing happens whenever we want to know more about the product, whenever we want to unfold its secrets in front of us. The real moment of testing creation has nothing to do with executing scripted activities – it happens in the moment we ask ourselves and the product the question “What if I do this now…?”.
If you ask a random person in testing – “What is testing for?” or “What is the purpose of testing?” you will probably get a series of answers that are mostly part of the truth, like: to discover bugs, to assure quality, to expose problems, to assess risks, which is fine, but not completely, because above all of these we perform testing in order to gain information about the product. Information that is vital in order to assess risk, find bugs or any of the above. Such information could be obtained only by exploring the product and all the assets that come with it – documentation, user guides, requirements, design plans, etc.
Problems with exploratory testing being a technique.
In different resources and according to some testers, exploratory testing is a technique of testing, and testing could be either exploratory or scripted, which I think is wrong.
Let’s start with a logical question – if we claim that exploratory testing is a technique and it can be completely replaced by scripted testing, how are we gathering the information that we will use in our testing scripts if we have never explored the application in order to make ourselves aware of it, what parts does it have, what complexity, etc?
There can not be scripted testing without the existence of exploratory testing. The claim that there could be a test script or a test case that doesn’t contain information or insight gained with the help of exploration and experimentation could mean only one thing – that we have a script or a case that has nothing to do with the real behavior and the real application, but rather with a model that we built, based on something else, but not the real product.
Yes, I know how many will try to counter this – how about documentation, user guides, online help, etc? Well, here’s a thing – having your testing based on the docs or any other artifact supporting the product is testing only the artifact or what that artifact claims for the product, not the product itself. There’s many occasions and I believe everyone experienced this where documentation is outdated or doesn’t exist at all. How do you construct your testing then, if you only depend on documentation?
The bottom line of this point is – testing’s main purpose is to interact with the product, to dig deep in it, to experiment with it and to explore it and this could only happen with the help of interacting with it, happily there’s no other efficient way.
Conclusion:
My opinion and based on what I learn and experienced so far, is that it works best if we approach testing a new product just as we would if we were conquering a new land. There’s no rules, there’s no limits, there’s no expectations – we get to know them on the fly, we adapt and figure out our strategy while we try to explore the possibilities this “new land” has to offer.
That’s it for now, see you next time. Don’t forget to share and retweet and as always I will be more than happy to read you thoughts in the comments. Good luck!
Mr.Slavchev
Senior software engineer in testing. The views I express here are mine, they don't represent any position held by any of my employers. Experience in mobile, automation, usability and exploratory testing. Rebel-driven tester, interested in the scientific part of testing and the thinking involved. Testing troll for life. Retired gamer and a beer lover. Martial arts practitioner.
Follow Me:
2 thoughts on “Software testing is.. part 1 – exploratory.”