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.ā
āNo problem!ā
ā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?ā
āGreat, thanks!ā
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?
Go explore
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.