Last month, we talked about visualizing dependencies. This month we want to go into more detail about using exploratory test techniques for more than exploring your new features in your product.
In her book, Explore It! Elisabeth Hendrickson defines exploratory testing as “Exploratory testing is simultaneously designing and executing tests to learn about the system, using your insights from the last experiment to inform the next.”
We like that explanation since it helps us find surprises, or implications of interactions that no one ever considered, or perhaps even the misunderstandings about what the software is supposed to do. To us, exploratory testing is the difference between wandering at random (lost?) and exploring thoughtfully (to gain insight).
Can we use these techniques to explore ideas instead of an existing product? For example, if you are coming into a team as a new member and don’t know anything about the product, instead of jumping right into exploring the product, first try exploring the ecosystem it belongs to. Maybe create a context diagram exploring inputs and outputs into pieces of the system, who (or what) is using it. Janet finds that a context diagram lets you design better exploratory test charters to question the system.
Elisabeth’s format for creating charters is:
Explore [the target]
With [what resources are available]
To Discover [information]
This type of format lets us focus what we want to concentrate on – it’s a form of deliberate discovery. For example, pretend we need to build an app to help us organize a move from one house to another. Lisa moved from Colorado to Vermont a while ago, so we’ll think of her as the customer in this example. One of the features needed, was the ability to create an inventory of everything to be moved and then assign it a box. Before we start building this feature, we need to think a bit more about it.
Explore [the inventory feature]
With [possible items]
To Discover [if all items can be labeled in this way]
We have now limited our scope to something quite specific. The questions we ask now to the product owner, or perhaps other users will focus on that aspect. When Janet questioned Lisa on what types of items she had to pack, Lisa started with her house … which made sense. Janet then asked about other buildings – Was there anything there that needed to move? We quickly discovered that donkeys don’t fit into boxes, so there was a fundamental flaw in our inventory process. We learned something by focusing on something very specific that was critical to our feature and exploring those ideas.
We talked about another technique to explore your requirements in our last video chat - is example mapping. We also suggest you read Matt Wynne’s article on the subject. https://cucumber.io/blog/2015/12/08/example-mapping-introduction
Put on your explorer hat, gather some of these tools to help you, and see what you can learn about your team’s new product and feature ideas!