Exploratory testing is a staple activity for experienced QA professionals, yet it is sometimes difficult to quantify the value of and need for it to a stakeholder or someone not integrated on a development team. There are several reasons for exploratory testing, including the QA window being compressed by a business need, ramping up a new team member on an existing team, and investigating related or adjacent functionality on a non-greenfield project. I reached out to our team members to get their perspective on how they perform exploratory testing and its value.
Exploratory testing emphasizes curiosity, creativity and autonomy. When we remove the scripting we allow ourselves as testers to be curious. We now have the chance to execute the “What if” scenarios. What would happen if I click this button multiple times? Beyond curiosity you need to be creative in truly how to break the system. Think really outside the box and execute those tasks. To get the most value out of exploratory testing I like to continuously perform this type of testing throughout the sprint. Put a time box on it daily. This enables you to learn about the system and give feedback as quickly as possible. Another thing you will want to do is write down a few notes of things you would like to touch on the system so you have a mission for that testing session.
Getting the most value from exploratory testing is usually a compromise. There is often a difference of opinion between the QA and the stakeholder as to what provides value. Many times, a stakeholder will want the exploratory testing documented step by step as "proof" that it was done. To me, this does not provide the value the stakeholder would expect. They may feel that this gives a repeatable path for other testers to use, but in reality, that path is less likely to generate bugs in the future (the pesticide paradox). I feel that at most, if there needs to be documentation, it should be far more general in order to promote different approaches to a workflow. That way, the end result can be reached through more paths in the app/website and a greater chance of finding new issues is realized.
For me, exploratory testing starts with a review of the acceptance criteria and any test plan I’ve created for a particular item. Once I’ve reviewed what is expected from the functionality it’s time to start thinking about the exploratory testing itself. The first place I start is asking myself the ‘mom’ question. My mother often calls me with issues using her smart phone or a website. She tends to click multiple times if she isn’t seeing a change, constantly refreshing the page to ‘make it faster’ etc. She has managed to break things in some very interesting ways, and then calls me to help her fix them. I try to envision some of the crazy things I’ve seen and ask myself ‘how would my mom break this?’ and I try to use that as a guide in my exploratory testing.
There are two ways that I look at getting value from exploratory testing. First and foremost, it can be a useful tool to put down your established test cases and take a "walk" through your application that you would not normally do. While most people will not deviate too much from their normal workflows, some will, and you need to try to account for the atypical usage. The other value is added more directly to the team than the project. Exploratory testing is great way to get a new team member up to speed on the project and product. This ramp-up can also provide value back to the team by getting the new member’s “fresh-perspective” through questions or ideas that have not been filtered through the rest of the team’s shared assumptions.