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.