On the 27th of August Simon Tomes and Elizabeth Zagroba (@ezagroba) will spend an exciting hour on The Club tapping away at their keyboards answering your questions related to Exploratory Testing. Ask your questions!
We’re Elizabeth and Simon, and we both love exploratory testing! We’re here to answer your questions. Feel free to ask us anything. We look forward to sharing our experiences with such topics as:
Getting started with exploratory testing
Structuring your exploratory testing efforts
Where tools can help
Testing with your team
Exploratory testing and its relationship to other testing activities
How to get the most out of your testing notes
Deciding how to share your discoveries and what to do next
Get your questions in before 27 August at 7pm BST, and we’ll share ideas to enhance your exploratory testing efforts. #KeepExploring#DojoPowerHour
Elizabeth, if I remember correctly, you shared in a talk at Agile Testing Days 2018 that you received feedback on test charters you wrote.
How much context is needed to provide good feedback on charters?
What do you suggest if there is no expert on exploratory testing in your organization that could provide expert feedback?
There are lots if different ways to take testing notes, thinking of the tool you use for this (pen and paper, text editor, screenshots, …) and the content that you actually note down (results matching your expectation, only things you see a potential issue, …).
Do you have a default approach for taking notes? How does that look like?
If you vary your approach for taking notes: What are the influencing factors that make you decide on the approach for a session?
Have you ever, or do you know of anyone who has, conducted exploratory testing in a regulated environment (banking, automotive, medical, etc)? What tips would you have for those who work in such sectors?
Most of the time when people talk about exploratory testing, they seem to be testing through the UI. What are your experiences doing exploratory testing on APIs or databases? Or in taking exploratory testing in a more technical direction than working with the UI?
It depends! In the story I told about the charters, the people knew a bit about the products that would provide the inputs for and consume the outputs of the API we were building. They weren’t familiar with our particular user stories, existing test automation, team dynamics, all of which would have contributed more valuable feedback.
I don’t think you need to be an expert in someone’s discipline to give feedback about their work. Someone less with your project’s context or exploratory testing (developer, project manager, product owner, tester on another team, etc.) might still helpful in reflecting on your testing activities:
Say you find something here, will you go fix that bug?
Is this more important than that?
You said you wanted to see what happens with this kind of data: what about that other kind of data?
If you only had three hours to work on this today, which of these charters would you choose and which would you postpone?
I struggle to characterise exploratory testing without sharing information that might read like a definition.
Here’s one way I think about exploratory testing: Exploratory testing provides us with useful insight. It helps discover problems that threaten the value of a product. Exploratory testing gives everyone permission to ask questions, share ideas and offer up compliments to colleagues.
Exploratory testing is a style of software testing that encourages freedom to think and explore within the constraints of a specific goal. It aims to answer questions about risks and relies on documented and shareable observations to help teams make decisions.
Exploratory testing is a testing approach and mindset used by testers and development teams across the world. Those that deliberately practice exploratory testing techniques find a sense of great fulfilment and joy in their testing efforts.
Exploratory testing means different things to people in different contexts. Its characterisation and definition creates debate within and outside of software testing communities. Its ok to interpret it how you wish.
Other testing activities might include things such as checking via automation tools and human checking using techniques such a test cases and test scripts.
I often turn to Dan Ashby’s model. I like how it groups testing activities by either assertive or investigative. The former checks against something explicit and the later aims to turn tacit and unknown information into something explicit.
And how cool is it that there are a tonne of power hours already devoted to other testing activities and more!