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.

Anna Baik took my recent blog posts and made a reflection on her swimming lessons in a blog post. In short, she stated that up until the age of 11 years she was not taught how to swim properly. Though her teacher insisted on some exam, she wasn’t able to take the test. In the end she did not learn swimming at school, but much later decided to learn how to swim with some advice from a friend. In retrospection I am going to introduce three different models for learning and education and discuss them in some depth.

Just finished reading through the rumble of the year between Matt Heusser and Alan Page on code metrics. Marlena Compton seems to have facilitated the session very well, since I haven’t heard of any casualties. One striking phrase from Alan Page led me to this blog entry:

In my world, code coverage measurement is another tool in the testers toolbox. We use different “tools” depending on what we’re investigating and where we want to guide our discovery process. We always need to use the right tool in the right context.

Thus far I haven’t thought consciously about context. Alan in the above mentioned quotation made me realize that there are multiple contexts to apply context to.

Last Friday I visited my old university where I studied up until just four years from now. The place where I learned how to learn. It was amazing how little changed beside the fact that students nowadays get charged a whole lot more money for their education. In Germany currently there is a rough discussion about these fees and that the universities do not take care for the educational side properly. The graduation celebration I visited last Friday was accompanied with a talk from a previous mentor of mine. He had some data on how education had changed over the last decade and made a comparison between the old Diplom courses and the new Bachelor and Master system. Reflecting over the past years and that talk, I came to the realization that there seems to be a gap in our industry currently.

What did I see or hear that leads me to this conclusion? Reflecting back four years from now I knew nothing about software testing. Over the last years of my study I concentrated on pattern recognition, like face-detection in images, and my diploma thesis handled about hand gesture detection in human-robot interaction scenarios. Back in April 2006 I joined a team of great testers and needed to learn software testing. Thus far I had not participated in a course on software testing. The team I was working in was doing a whole bunch of software test automation using shell-scripts. Over the course of the next few years I did learn how to teach myself what software testing is about. I learned that software test automation is software development, I learned that exploratory and sapient tests are very worth the effort, when accompanied with the right organizational methods, and I learned a whole bunch about Craftsmanship and Cooperative learning sessions.

In general I would conclude that I learned almost eighty percent of the stuff I need on a daily basis right after leaving the university, while the material I learned in university is not that relevant for me any more. As a software tester I don’t need to know how a wrenches for robot hand motorics work, since I don’t need them. Multi-layer perceptrons are not an option for me. Learning algorithms like AdaBoost and online and offline algorithms are not needed in order to test software. Well, I wouldn’t claim that the rough six years I spend at the university were wasted, but I feel that I dd not learn the right things there.

Recently I noticed that there seem to be others who feel just like me. The Software Craftsmanship conducts coding dojos and programming katas to teach the apprentices what the universities are not teaching them. Design Principles like SOLID and Design Patterns are taught on a on-the-job training between Journeyman and Apprentices. For software testers there are similar things happening, i.e. James Bach and Michael Bolton created a Rapid Software Testing class, Cem Kaner has also great courses. Yet, besides Cem Kaner and other distinct persons we do not seem to have reached the universities with our efforts. When I took a course named “Software Praktikum” back in the year 2000, people were talking about test-driven development and that new movement called eXtreme Programming, but no one really taught us something about it.

When I took a look on the course material nowadays I found out that the situation had been improved over the last few years. Nowadays students get offered test-driven development courses, some Design Patterns and maybe some Refactoring. Unfortunately I did not run across a testing course at my university.

Therefore I concluded that I would like to do something on this as part of a New Year’s resolution. Personally I want to help people understand software testing, help them grow into the craft and hopefully get a better tester than I am. There are a lot of movements currently going on, and I think based on my past I can be a contribution to these movements. This is all I want to say for now. If I made you curious about more, you may want to subscribe to my feed, as I will be digging deeper here shortly.