One of my goals this quarter is to read a book called Explore It! by Elisabeth Hendrickson. This book is said to be a leading title in QA exploratory testing, and gives definition to, and practice sessions on, exploratory testing efforts.
I am one chapter in at this point and already love much of what was said. I hope to continue writing about the book as I read through it.
If you don’t know what exploratory testing is, Elisabeth defines it as:
Simultaneously designing and executing tests to learn about the system, using your insights from the last experiment to inform the next
Basically, she gives an analogy about visiting a different city, and how there are main streets with tourist attractions, but also back streets with hidden gems. She uses this to describe how we should interact with our products while testing, to not only test the acceptance criteria but also explore different areas where hidden gems may exist.
I have heard and really like the term “barely sufficient coverage” when describing my test steps. I write those down just before, or sometimes during my exploratory testing. Those often will layout what the product manager has in mind when they described the acceptance criteria. But even the most well written test plan cannot cover all the scenarios that exist when your users start getting their hands on your product. Writing barely sufficient coverage allows you or a future tester to understand what was expected in the product, but shouldn’t write down every possible path that could be taken. This removes the idea of exploratory testing.
Elisabeth states that “Exploratory testing involves scouting around the areas that the net doesn’t cover.” She uses the word “net” to describe checking the product for expected results, often, what is included in your test plan. But then says that a fully tested product is both checked and explored.
My favorite technique that she defines about exploratory testing, is that when you have an idea for a back road test, you act on it right away. Don’t write it in a test plan to perform the steps later, don’t plan out the testing session and possible outcomes, because as you explore, those will naturally happen and that is when you begin to uncover bugs that the user will most likely encounter.