It’s a lovely day. A gentle breeze, warm but not too warm and we’re outside playing croquet and I’ve got a sledgehammer. Hefting this 3ft, 5kg head at the ball I swing… and almost delicately, that great lump of metal sails through the air and smashes the greenhouse to smithereens. I cross ‘Lump hammer as croquet mallet’ off my list. More importantly, I’ve learned the head isn’t secured to the haft properly. Reattaching the head to the haft and giving it a bash just to be sure, I eye an innocent and much-loved plant pot and practice my backswing….
Putting the ‘explore’ in Exploratory
There are as many definitions of exploratory testing as there are Costa Coffee houses, but the common thread through them all is that you, the tester is actively investigating different ways to use the product. Scripted tests from acceptance criteria will tell you what a device should do in ideal conditions. Automation will tell you consistently what happens under X condition. The load will tell you what conditions are needed for the product to break but exploratory testing allows the tester to think about the product.
We know for example, that a sledgehammer is designed to bash down a brick wall, but – in our example above, what if the user takes it to plasterboard? Concrete? Granite? These materials are different to brick and so we want to understand how the product behaves when bashed against them.
Subverting expectations
We might expect our customer to use the hammer in a certain way, then find that it operates completely differently outside of our expectations. Such as when held differently (Apple, we’re looking at you).
Exploratory testing affects the tests we write: We can learn that when the head of the hammer hits granite, the metal head dents or deforms. The customer needs to know about this edge case, so we create a test for that environment.
Exploratory testing is efficient. Usually, there are no scripts to complete or write out, rather such an approach generates tests. If your application is using RFID tags for authentication, exploratory testing could place two readers beside one another. What happens when the wrong device picks up the signal and the wrong door opens? What if this was an emergency or a safety/security alarm was set off because of the proximity of the readers? What if a gents tag opened the ladies loo?
The biggest benefit of exploratory testing is – not only an exercise in creativity – but the efficiency of the work. You’re testing, just without the rigid formality of test scripts. You’ll still create them but from a brief note. You are thinking quickly, adapting, learning and setting up edge case scenarios that just wouldn’t occur to a structured approach.
In practice
Exploratory testing should be done early and often, with time set aside within the sprint. Sometimes, when there’s huge pressure to release a product you can only do exploratory testing. That’s fine! As a professional you know what you’re looking for because you’ve read the acceptance criteria. You know what the product does and with only a short time to smash the wall down you’ve created your environments and considered your edge cases. You need to use this lightweight, brain driven method to prove the quality of your product: such as playing croquet with a sledgehammer.
Creativity and lateral thinking are the best ways to explore a product and make it more than just functional. Exploratory testing is often the hardest form of QA to make it effective, but it is also the most rewarding opportunity to demonstrate curiosity, intuition, creativity and passion that makes testing enjoyable.
See you on the field.
