## Wednesday, March 24, 2010

### Using James Burke’s CONNECTIONS to Aid in Testing

There are places and times where revolutionary and paradigm changing discoveries can be made. Socrates and Aristotle changed paradigms, so did Newton, Einstein, and many others. The way we were able to look at things and the map that shaped those views was forever altered by these thinkers. In the everyday world, few of us get to have the ability to change paradigms. To understand how hard this is, it’s important to make the comparison with something that really did change a paradigm.

Here’s an example I remember reading about many years ago regarding breakthrough discoveries in Mathematics (J.J. O'Connor and E.F.Robertson wrote about this in 1997, the full URL can be seen at

A challenge

If you think that mathematical discovery is easy then here is a challenge to make you think. Napier, Briggs and others introduced the world to logarithms nearly 400 years ago. These were used for 350 years as the main tool in arithmetical calculations. An amazing amount of effort was saved using logarithms, how could the heavy calculations necessary in the sciences ever have taken place without logs.

Then the world changed. The pocket calculator appeared. The logarithm remains an important mathematical function but its use in calculating has gone for ever.

Here is the challenge. What will replace the calculator? You might say that this is an unfair question. However let me remind you that Napier invented the basic concepts of a mechanical computer at the same time as logs. The basic ideas that will lead to the replacement of the pocket calculator are almost certainly around us.

We can think of faster calculators, smaller calculators, better calculators but I'm asking for something as different from the calculator as the calculator itself is from log tables. [...] Think about it and realize how difficult it was to invent non-euclidean geometries, groups, general relativity, set theory, .... .

I remember listening some time back to Dan Carlin’s “Hardcore History” podcast, and in particular, his interview with James Burke. For those not familiar with James Burke, he is an influential historian who developed and presented the "Connections" series on PBS and BBC back in the late 1970’s. His idea was to look at the notion that knowledge, and history, isn’t just a linear march from point A to point B, but that there were many cross sections and encounters and ways of influencing people that work its way into history. James makes the point that he could draw connections from Mozart to the helicopter in less than ten jumps, and only touch on music twice. It was James Burke’s Connections idea that has spawned something that I do in testing now that I also refer to as “Connections Based Testing”.

The idea is not far removed from integration testing, but the method I use is to see how many different avenues and paths I can travel down without going back to the same section, and see how many “maps” I can create. By necessity, some of these maps will be very short, because there will be very little interaction with another unit, but often, there can be marathon stretches of code interactions that will take many, many steps. I find these options to be interesting test case stories, as often they will open up new avenues that I otherwise would not consider. This becomes especially important if an application integrates with other applications (say, Outlook, Word or Excel in the large application sense, or with Flash, JavaScript or Ruby in the web sphere).

I recently had an opportunity to see where an application I was working on interfaced with multiple moving parts, both within the application and calls to external applications, and determined that there was a triangle effect in place, that Part A called Part B, Part B called on and used elements of Part C, and then Part C referenced Part A again. It was in this triangle, if anything broke on any of the legs, the functionality would be broken all the way around, or would work much less effectively in the perception of the stakeholder (which many times equates to being “broken all the way around”). If we tested these items individually, we would not see the specific issues, but if we followed the connections, we would see the problem, and be able to determine what actually went wrong.