Saturday, April 25, 2009

Art, memorials and software testing

Last weekend I was in Berlin with a couple of friends. Just to celebrate our friendship. One of the things I saw there was the Jewish Holocaust Memorial. It is an impressive huge monument of pilars.

As I don't read manuals when installing software so I also didn't read the introduction of this monument. The process of experiencing I had of monument made me think about similarities within software testing.

Initially we stood there wondering what to do. We noticed standing outside the monument that it has a beginning and at the horizon we saw there was an end; although we couldn't see the last stones. It has also sides and you can enter the monument from any position. Another observation was that the pillars stood in obvious straight rows and in line; they seem to be gray and of different sizes. From the point I was standing I could only oversee a small part of what is happening in the monument as not all paths were visible.

Except of just standing there and accepting the monument as it is we tried to learn more from it. We got the idea just to step of our rented bicycles and take a walk across the field of pillars. At that moment there was no defined plan. We just walk to see what is at the end.

Initially I walked with 2 other friends telling each other what we saw which we couldn't see standing outside the monument. Some findings were like: the pillars are not straight in line at all. The bricks on the floor might also be part of the monument. The pillars don't have all the same size and same gray color. The floor is not equal, although we noticed that it had some curves from out starting point to the obvious end. It curved also sideways. Between the bricks on the floor there were lying small stones of almost equally color.

After a few minutes walking I did what most human beings would do, I start playing. While we started walking together in the same direction it was very easy just to step to the left and "loose" the friends, walk a bit faster and pop up just a few stones ahead while they didn't noticed it. This was the trigger, they started playing along. In the beginning we had no direct goal, only to see if we were able to surprise each other showing up on a different position.

In the beginning we knew in which area the other was, when stepping behind from some stones or crossing other lines and catching a short view of the shoes or jacket. After a moment we were so busy to surprise each other we lost each other. This brought me back to the monument and I made my own context what the monument should represent. I realized how easy it is to loose dear friends with just a small action. In the beginning you know were they should be, after a while you just know they are somewhere, and at the end you don't have nothing; just the believe that they are still there.

After I lost the friends in the monument I tried to find them. I figured out a plan how to approach the web of pillars, walking different routes with different speed. Assuming that they are going from beginning to end I started to walk from left to right. I also deliberately walked the same route back and also backwards. Just to get some information which should give me a clue in which part they were walking. After a while I accepted that I lost my friends in the maze and continued walking alone.

At that moment I noticed I went back to my initial goal: to learn from and experience the monument. Based on my gained knowledge I reshaped the context of the monument. It is not just a pile of stones lined up. It has also the ability to loose people (information) or to gain information (meet other people). I now walked between the pillars just to see what others are doing. I watched their behavior in the center of the monument and also at the borders. I now noticed that some people are doing the same as what I did with my friends. Others were just walking through and talking to each others. A few were using the paths to get to the end and at certain places people were just sitting thinking about the monument or enjoying the nice weather.

That day I learned a lot. Therefore I'm writing this blog. What I learned/did was:

  1. approaching a object not based on best practices, instead asking myself questions what could be the purpose of it and what can I do with it. Thinking about possible value
  2. approaching the object with questions
  3. observing what I see while I experience and trying to redefine new questions
  4. what initially wasn't there can be of importance later on like the difference of depth in the object
  5. rules changing: initially we were just walking, then trying to surprise each other, losing each other in the game, accepting the lost and redefining goals
  6. context is changes after a while
  7. items change of importance: the little stones between the bricks. At a certain moment they had some value. Only at that moment when the thought arise they keep the bricks together
  8. Different moments need different questions and lead to different observations
  9. I would have missed a lot if I approached the object with a fixed plan based on best practices
  10. I enjoyed being there, walking there, learning from it.

Sunday, April 5, 2009

Sun Tzu Art of war and software testing

Finally I found some time to start reading Sun Tzu's The art of war.

In one of the first pages I noticed some text which might explain why it is hard to manage a test process.

"A general must see alone and know alone, meaning that he must see what others do not see and know what others do not know. Seeing what others do not see is called brilliance, knowing what others do not know is called genius. Brilliant geniuses win first, meaning that they defend in such a way as to be unassailable and attack in such a way as to be irresistible. (Thomas Cleary, page 7, Sun Tzu: The Art of War)"

Imagine that you have three generals: one general from business, one general from development and one general from software testing.

As a general from software testing you stand in between the war zone from the other generals. They expect you to provide information so they see what you see about the system and the process. For example: does the process to create the system contain enough information to meet the requirements. They also expect you to provide information so they know what you know. For example: are there some defects in the system.

If the software testing general has to give the views and knowledge away, he can barely be a brilliant genius. Although this is often what the other generals expect from him as he should give positive news about the quality and an advice to go to production. In this case he will give away his knowledge and views away.

To me it seems that we should keep providing this information which will lead that no one will see you’re a brilliant genius. Also you cannot fulfill the role of a software testing general as you will not be successful when you have to give away all information.

Wednesday, April 1, 2009

Magazine: Quality Matters, now with contribution of myself

Recently I send in an article with a though I had in my mind for some while about improving test processes. Sometimes it is better to neglect improvements how obvious they are.

In the 2nd edition of the magazine: Quality Matters my story is presented under the title: "Be innovative! Stop improving your test process."