Adam Knight spoke at the Cambridge Tester Meetup last night on Fractal Exploratory Testing, a topic he’s blogged about a couple of times:
Fractals can be roughly defined as having similar properties whatever level of magnification you apply to them. The Mandelbrot Set is a famously fractal shape and zooming into into it exposes characteristics that make each image recognisably from the same family. Going 10x or 100x into some other image, say a photograph of my head, would not have the same effect.
There’s an analogy to be made with Exploratory Testing – in fact, with exploration of any kind – and this is reinforced by Adam’s choosing to cast exploration in terms of charters written in a concise but formal way inspired by Elizabeth Hendrickson along the lines of “Explore <area> with <resources> to achieve <aim>”.
Each exploration uses appropriate testing approaches to attempt to achieve its aim and sometimes succeeds. However, along the way it might expose another area of interest, or fail to because it instead finds something else, or is blocked for some reason or an assumption about the mission proves false and so the charter is invalid or …
Each of these outcomes can themselves pose new questions, which can in turn inspire new charters, new explorations which will look just the same as the mission which spawned them in all relevant details: they will have a charter in the same format and the same kinds of testing techniques can be used to execute them.
In a fractal, you can magnify any part to any degree. It’s a mathematical paradox that coastlines tend to infinite length: the greater the level of magnification, the greater the possible resolution of the ruler, the more small deviations that can be observed and measured. And which of us hasn’t from time to time got so engrossed in a testing task that we’ve burned through hours of investigation focusing on increasingly detailed analysis of some aspect of a product and still thought that there was more we could do?
Adam’s insight in this talk wasn’t to do with exploratory testing, nor even how thinking about fractals can help a tester in their testing missions, particularly, but much more about how describing testing in this recursive way can help to explain why, for example:
- on a project with 10 requirements, there aren’t merely 10 test cases to be executed before the product is shipped
- estimation of testing time “required” is not necessarily a simple calculation
- focus on different areas of the system under test might differ radically, depending on what exploration in those areas found
He talked about how he has used fractals to explain testing to non-testers and particularly to non-testers on the business side of the company. They might not “get” testing but they can understand a picture of it which shows that successive rounds of investigation are defining the differences between the specification and the product that was delivered. The level of investigation in a particular area can increase the resolution with which the size and shape of that area is understood.
Decisions from the business, based on what’s known at any point, can then be seen to be guiding further testing into a new area or choosing the magnification of some existing area that is most important to get the information that will motivate the next round of decisions. The alert members of the business side might then themselves see that they have become engaged in a fractal process too.