By Simon Tomes
Learning about your product during an exploratory testing session is key to terrific team conversations. You might wonder why you want to learn about the product you’re building. Isn’t that for the product owner or product manager to worry about? Surely it’s their product? It isn’t. Any member of a development team can and should contribute to a product. Any team member can and should help the team get closer to the desired outcomes of a customer, user or business stakeholder.
Something amazing happens when an explorer shares what they’ve discovered during an exploratory testing session – the testing technique that’s a balance between scripted testing and try-to-break-it testing. Sharing with just one person in the team is enough!
“Thanks for this. Glad to see everything you discovered. I’ll fix the major bug you found! Am I right in thinking that you tested this in one particular state? Did you consider that this app has more than one state?”
“Ah, I didn’t consider that! Thanks for letting me know.”
“So I think we need to run another session to explore the risks associated with different states. For that I think we’ll need to use a state model to help us and we can try out different sequences to find vulnerabilities. I’ll set up another exploratory testing session for that. How does that sound?”
Exploratory testing is a together-learning technique to discover what is and what might be. The short feedback loops ensure no-one on the team is left behind. And discussions typically lead to a set of actions. You might raise a bug in your bug tracking tool. You might add an idea to an agenda item at your next product backlog refinement session. Your next planned exploration might change based on information and a discussion of the previous exploration.
💡 Try this
Set a 30 minute timer and explore something a developer has just made available to test. Takes notes – capture what you discover and what you think.
Clearly label any problems you’ve found, questions or ideas you have and highlight points of praise for the product or the team’s efforts.
Ask to sit with the developer who worked on the thing you explored. If remote, set up a video call. Set an expectation you’ve made notes and would like to share what you discovered.
Walk them through your notes. Talk about the items you feel are most important to share. Alternatively, chronologically walk through your notes.
Seek clarification to ensure your audience understands.
Be open to a discussion. Agree on a set of actions. Thank the person for their time.
How did it go? What did you learn? What actions did you establish? How has the conversation influenced your next exploration session? What surprised you about the debrief?
You can apply exploratory testing to pretty much anything – you don’t have to just explore a working application. You could explore a mockup, systems diagram, API, acceptance criteria on a story, some ideas, a database, a process, assumptions, specifications, a wireframe and more!
However, it’s not just a case of “sit down and talk with a developer” to keep these collaborative iterations going. Often we have a lot of information to share and it can be difficult for the receiver to consume it all. Structure your exploratory testing notes by labelling problems, questions, ideas and praise to give your audience the power to engage.
Use exploratory testing to create meaningful conversations and actionable feedback loops with your team. Exploratory testing is the key to continuous learning, smarter prioritisation and better-informed product decisions.
Simon is a CommunityBoss at Ministry of Testing and his pronouns are he/him. Currently learning to be a better community enabler, he has a passion for all things testing with a career in various testing roles since 2003. He particularly enjoys promoting and sharing the value of exploratory testing.