Monday, December 11, 2006

Victim of CMM Level 5

When the CEO of announced that he wants to head to SixSigma level 5 I felt sorry for all those poor bugs. Finally we will have enough time to find all those little creatures and throw them out of the system. While drawing a few poor bugs who lost their jobs – or who were detected - after searching for them as part of the new programme.
This is a remake of the original cartoon drawn in 2006. The original cartoon had only 2 bugs.


Wednesday, December 6, 2006

Stealth Deployment

This is a rework of a cartoon I drew in December 2006 based on a story that happened almost exactly like the cartoon demonstrates. I was "CC"-ied an Email which the head developer at that time answered to Engineering team. He forced them to deploy a piece of code while bypassing all agreed software deployment processes. And it wasn't the only time we suffered such actions. The original version of the cartoon together with one of my first contributions as an author was published later by BZMedia, N.Y. (New York)









Wednesday, November 22, 2006

90/10

One day, a furious CTO invited the head developer, an architect and me into his office and started shouting. We were made responsible for the loss of a several million-dollar deal. I cannot remember the exact details anymore, but I remember being confronted with charges that could be easily disproved. Disappointed about the unfair treatment, I started to draw my very first cartoon. It served as a tool to channel my anger. When my colleagues saw the cartoon, they enjoyed it and couldn’t wait to see more of the same kind. So I continued drawing.

The term 90/10 was one of 3 slogans that ruled the company. 80/20 which is the well-known Pareto principle, 30/30 should remind us that one third of what we do is waste, and 90/10 meaning to take ownership. You are 90% responsible of what you do. In the cartoon, the numbers are twisted by purpose as this CTO didn’t follow his own code of practice.

 

 


Friday, November 17, 2006

No idea

The challenge of getting the required information is well-known among testers. Even if you get the required documentation, what you really need is missing. I have seen a broad variety of documents with different levels of quality (from excellence to unusable) but the experiencie I liked the most was a project that combined two very different approaches in two different phases of the project.
The project started as an XP approach where the system was built from scratch; as the tester, I worked with developers and the project leader. During that time I learnt the application inside out, even though there was not much documentation around. After the program was shipped, we shifted to phase 2, from XP to a more classical approach where the developer and the BA wrote just rough specifications. After the initial version was built, I got release notes with valuable background information written by the BA and the developer. Even at a late stage in all the following phases, reading those release notes was enough for me to understand exactly which extensions were introduced and where I had to look for defects because I knew the application well from the first phase.

In another project that came with poor documentation, target users tested the system every six weeks for a whole week. During that week we delivered fixes every day and agreed on new features for the next iteration. The product quality was amazing. RUP and XP were foreign words at that time.
In cases were no or or poor documentation is around, I ask developers to present the features they have introduced rather than forcing them to write poor documentation that contains only half of the required information. Rather than focusing too much on requirements documentation, it is more imporatn to have the team close together and make sure you get the information you need to come a comain expert of the AUT.