There are many ways to test a software product. There are many methodologies that could help in testing that software product, so that the final release contains as less bugs as possible. We are not at the point where we could say that we have found the solution for bug free applications. But we are at the point where we know that in order to avoid buggy, hard to use, no precise scope defined applications, we need an approach that will ensure a higher quality of the product. One of these ways could very well be Exploratory Testing, done right, done different. Exploratory Testing is important. Exploratory Testing can be learnt.

In my opinion, these are some of the messages that can be heard when reading Explore It!, by Elisabeth Hendrickson.

As Cem Kaner himself states, Exploratory Testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/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’s a pretty accurate definition. But what does this mean exactly? How could I learn to be a more creative individual, when all around me and my work requires 100% analytical thinking? Do I need to be more creative, or to have a better sense of responsibility in order to execute exploratory tests that actually find defects and weaknesses?

I’ve started looking for some of the answers I need through “Exploratory Testing”. I have to say that I found the book incredibly easy to read and captivating. The real-world examples were in the right places, and I could better visualize the applicability of a concept presented in a specific section. However, at some point, I felt that the examples became too detailed and a more high-level explanation should have sufficed (but this is maybe a singular opinion, I guess it depends on our own perception on exploratory testing). The personas concept is something I have never thought of and it’s definitely something I would like to try with my team someday. The idea of role playing of well-defined characters, in order to cover more classes of vulnerabilities is one of the many out-of-the-box examples and concepts that are defined in this book.

All in all, I sincerely recommend this book for any tester who would like to better themselves. It is suitable not only for functional testers, but it also has a few interesting approaches for the non-functional parts of the system as well. It has great advices on how to perform a good interview and how to do well on an interview, when faced with testing unfamiliar applications.

What I realized is that I found a few answers, but I have also discovered new questions and for me, this is more important. It means that the book got me thinking and questioning - how could I become a better explorer?