Reading a Book: Explore It!

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.

Explore It!

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: