Late January 2016 Adam Knight @adampknight gave a talk to the software testing club about his thoughts on ‘Fractal Exploratory Testing’. I popped along to this as it was something I hadn’t heard about before.
Adam has previous written about this topic on his blog
A fractal is a natural phenomenon or a mathematical set that exhibits a repeating pattern that displays at every scale. wikipedia
Adam started with an example from the Lewis and Clark expedition. He used this to show how exploration can work in practical examples. Lewis and Clarke were given a main objective by the president such as “to explore and map the newly acquired territory, find a practical route across the Western half of the continent, and establish an American presence in this territory before Britain and other European powers tried to claim it.”. They also had a secondary objective “to study the area’s plants, animal life, and geography, and establish trade with local Native American tribes.”
He used this to explain how all exploration starts with a single mission, which guides and directs everything else that follows. Under the main mission will likely form sub missions, and under them further sub missions and so on. The output of one mission or experimental result will drive the next one. The main aim of the exploration work gives the overview and context, but Adam argues that isn’t ever enough, hence the need for sub missions and tasks.
Importantly while the work may be the same, depending on the context of which part of the mission you are in influences how you respond when asked about the work you are doing. Someone might need to know your sub mission or they might only be concerned with the main objective. Adam used the story of the three stone cutters to highlight this. In summary three stone cutters were all working on separate but similar pieces of stone. When asked what they were doing the first replied “I’m cutting this stone”, the second replied “I’m shaping this stone to fit in a wall”, the last stone cutter replied “I’m building a cathedral”. All doing the same task but each had a separate view about their mission.
Adam now went on to the main point of the talk and that was about fractal recursivity and how it could be used as an example to explain exploratory testing, or testing in general to other people. This is important, it really is just a model that describes testing and how it usually works in practice. It’s not about how fractals can be applied to testing.
Just like how fractals have repeating layers, exploratory investigations prompt further investigations. Risks prompts further investigations. Testing prompts further investigations. Adam mentioned that for non-testers using fractals as an example it was easier to explain why say eight requirements don’t necessarily have eight test cases, or how when estimating time for testing it all depends how deep you go or what you uncover when you get there.
Exploratory testing shapes itself to the risk. Your tests are built to what is there rather than what you hoped was there. It is in this way exploratory testing differs from scripted testing with its feedback loop.
Adam concluded that the value in this ‘model’ is in demonstrating that an exploratory approach can be applied equally at many levels.
Some questions from the audience at the end where around risk, in that the deeper you go the more risk there might be, when do you stop?
Other questions were about if this is more useful for teams of testers in that they all need to understand the bigger picture and work together, what about individual testers?
Others have blogged about this as well so please have a look at