As software testers we use context to point out that not all practices may be used in any situation. This is one of the key principles of the context-driven school of testing. Robert Martin talks about particular practices in the professionals tool-belt that are used in a project based on the particular context of that project. Alistair Cockburn names the same concept Just-in-time methodology construction and defines a large amount of practices and principles to use in software development projects. For me there always seemed to be a pattern behind this concept and I decided to write it up for public discussion.

Lately, I read through the Quality Software Management series from Gerald M. Weinberg. In it, Weinberg discusses differences between the Routine organization and the Steering organization. The key difference between the two organizational cultures lies in following a prescribed way to handle a project and choosing among several techniques and practices based on the current situation. In a Routine organization there is one particular process defined and software projects shall follow this. Of course, project managers take care of following this one process. In the Steering culture there are many processes which may be followed. In a Steering culture the controller of the project chooses among several practices and knows when to adapt by taking the outputs of the previous project phases and feeding this knowledge in to the inputs of the next project phase. A controller of the project may consist of the designated project manager or the project team as a whole.

About two years back my wife amazed me with a similar lesson in a completely different area of life. For my birthday I got a jigsaw puzzle. My wife has over hundred puzzles in the house and she all finished them. When I got to know my wife, we spent several evenings together puzzling. During this period I had adapted a technique from her to get the puzzle started. By sorting out similar shapes and then combining them according to their particular shape-type, she was able to make steady progress with the jigsaws. Therefore I started by doing the same thing. Having finished the outer frame, I sorted the remaining pieces by their shape and started over.

After some hours puzzling, I realized that copying this strategy did not work out for my puzzle at hand. I did not make much progress and had become a bit fed up with it. After reflecting some minutes, I realized that I was stuck by the wrong strategy. The puzzle showed an image of penguins in an icy world. Therefore the pieces contained mostly black and white fragments of that picture. It was a lot easier to first partition the pieces according to the color rather than their shape. My wife applied the strategy by sorting out shapes with more colorful puzzle images, that helped her succeed there, but for the image at hand I had focused on the wrong strategy. After changing it I noticed that I could make much faster progress than before.

Of course, in the story above I had less experience with jigsaws than my wife had. Over the years she adapted several techniques for finishing up a jigsaw and based on the particular circumstances she choses among the several techniques she knows. When I started the jigsaw I had a vague understanding of one of her techniques and foolishly tried to apply it. Just by making myself aware of the situation when things did not turn out, I was able to try out a new approach to follow and add another technique to my repertoire. Similarly in software testing and software development we need to make ourselves aware of the particular situation in our project and reflect over the course of it. When we get aware about problems, we can help ourselves by choosing another technique or practice to follow for the next few weeks in order to improve the overall course. By continuously making ourselves aware of the situation and the context at hand, we can deal with changes circumstances and try out new things if we get lost.