Before I begin with this post, I cannot help to feel the need of sharing with you a little bit about myself. My name is Andrés R. Curcio, and I’ve been in IT for over 10 years now, and 7 years working in Testing.
Nowadays, most of my knowledge comes undergoing a testing career for professional training, reading blogs from like-minded people, sharing thoughts with colleagues, with friends, participating in forums, and also, from purchasing, reading and understanding books, not to mention applying that “understanding”, and most certainly and positively, making mistakes and learning from them with a continuous self improvement drive.
All of those ingredients together have made me gain friends, knowledge, wits, experience, and scars as a consequence of thinking and tinkering outside of the box.
Ultimately, I can tell you that I enjoy this craft, this art, and I love it passionately.
SO, WHAT DOES THAT HAVE TO DO WITH THIS POST? WELL, THIS IS WHERE THE JOURNEY INTO EXPLORATION SETS OUT
When I first came across with Exploratory Testing I was starting my career in the craft, and it was presented as though it was a technique as opposed to an approach, so I was unable to tell the difference I see nowadays between those two.
I was employed as a Quality Assurance Engineer, and my responsibilities were building environments, as well as running the multiple test cases through a large variety of operating systems versions, and whilst doing so, testing the installation of the product. Eventually, all novelty faded out from the work, it all came down to running the same test cases over and over again, almost having mentally automated the process, so you could say that at some point I was not testing anymore, I was running and checking test cases.
Therefore, at the very beginning and out of lack of knowledge, real understanding, and expertise, “doing exploratory testing” felt a lot like this:
SO, WHAT DOES EXPLORATION STANDS FOR ME?
Time passed, and eventually my intuition and curiosity kept telling me there had to be more to testing than merely running test cases and checking results, I was convinced there had to be more to it than just that. So I resumed my investigation, my quench for knowledge and learning was alive and kicking, it was then when I came across with people who thought about testing in a similar fashion, it was then when I came across with people like Cem Kaner, James Bach, Jonatan Bach, Michael Bolton, and who nowadays happens to be a colleague and a friend of mine, Ignacio Esmite, to name just a few.
From them, I learned that testing is a lot more than running test cases and checking results. Moreover, I learned that exploratory testing is not a technique, but a highly valuable approach to testing.
Now, let me share a widely known definition on Exploratory Testing:
“Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”
That definition is a mouthful, isn’t it? You see, it mentions plenty of things that define the approach, the style, and most importantly, it broadened my mind. It taught me that testing:
- Required two levels of “responsibility”, personally and professionally speaking;
- “continually optimize the value of her work”, meaning (at least for me) that it would challenge me to keep on learning, challenging my knowledge, and what I thought I knew;
- “treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.” ¡I was in awe! I could test, learn, interpret results, bring about new testing ideas and challenge assumptions through critical thinking, and give value using knowledge, and all of that in parallel, ¡because those activities were mutually supportive!
So, in time, exploratory testing and testing itself, started looking and continued looking like this instead:
Because all those activities are being done in parallel, and, considering the context of the test item, Exploratory Testing started making a lot more sense as opposed to following a script, which most likely would easily and rapidly become outdated, and working upon them would take a lot of time. Exploratory Testing came out on top as a more dynamic, faster, efficient approach with which I would be able to provide value onto the team.
All in all, does that mean I discarded the Scripted Testing approach? No, it doesn’t. I have not given up on Scripted Testing, and I don’t think I will at all. As a matter of fact, it is my opinion that they both are part of Testing itself, therefore, Scripted and Exploratory Testing need to live, and at times, work together to accomplish a mission. However, Exploratory Testing requires a tester who continually strives to improve skills through training, learning, self-management, and daring to generate, as well as sharing and applying knowledge. Having that said, I would like to share the following blog post named Exploratory Testing 3.0 and it’s written by James Bach.
From those aforementioned reasons, and plenty of experiences I’ve had the chance to go through over the course of time, Exploratory Testing is definitely my preferred style. What is yours? What are your thoughts? We would like to know from you :)