The Test Management Octopus

April 5, 2011

There are some interesting comparisons between Octopuses and Test Management. For starters did you know that an octopus doesn’t have eight arms? Turns out that it has six arms and two legs (How Many Arms Does an Octopus Have?). Either way that’s a lot of limbs to manage. The management of the test process presents most of us with a similar challenge.

The concepts behind test management are simple. Think up a test case, define the steps, write down the expected results, execute and log the result. It all boils down to this. The larger the product we’re testing the more we need to create. You couldn’t wish for simpler foundation. Simple is great, especially in the software development arena where complexity seems to reign.

Simple as in an Octopus has 8 arms is good too. Only it doesn’t. On closer inspection an Octopus effectively has six arms and two legs. Observations have shown that an Octopus uses the two rear most tentacles to get around the seabed. The other 6 for propulsion when swimming and manipulating objects. Research has also shown that when octopuses get in a tangle they use two specific tentacles to help untangle themselves. Simple on the surface. Not so simple when you start to look a little deeper.

This goes for test management too. The principals of writing and managing the documents are simple on the surface. Scale things up and you’ve got 8 tentacles that frequently seem to get tangled up.

Managing this in practice becomes very complex very quickly. The end result never seeming to be as clear cut as the simple foundation. Sticking with Octopus analogy I’d suggest that there are 8 test management tentacles that result in this complexity:

1. Multiple testers adding, deleting and modifying documents concurrently.

2. Evolution of documents over a period of time requiring version control.

3. Running different versions of a test case against different versions of the product, means multiple different results.

4. Linking results to the requirements in order to track coverage.

5. Some organisations impose a review process covering the written documents.

6. Managing variations of very similar test cases which are written for product or module variations.

7. Tracking the execution against the same version of a product being run on different configurations/environments.

8. The need to Identify which test cases need to be re run when a defect is fixed and requires re-checking.

The concept of one test case, one person, one requirement and one product version is clearly easy to comprehend. It’s the eight tentacles that start to add layers of complexity. What happens when multiple testers are adding, deleting and modifying the repository of data concurrently? This delivers similar issues that developers face with source code control. Only it’s more complicated for us when you add in the next tentacle. That tentacle being the need to run different versions of a test against different versions of the product we’re checking. Then link that in to another tentacle where you need to link those cases back to the requirements that they cover (where the requirements themselves are like shifting sands in their own right). You get the picture. The result is eight legs of a test management octopus that are damn difficult to keep track off.

Octopuses are one of the most intelligent forms of sea life. They can manipulate Rubik’s cubes and learn to open jam jars. Whilst the test management process is hardly as simple as opening a jam jar I would suggest that we’ve got a creature which is far more complex and fascinating than many seem to give it credit for.