The Code Whisperer

Let me say straight away that, outside of unit and system testing, I’m not an experienced tester. I believe you have to have a certain mindset to be really good at it and, although this may seem harsh, a passion for breaking things rather than building things, albeit all for the greater good. I met a number of exceptionally good testers in the past and they all share similar approaches, plus a slightly mistrusting look in their eyes.

The amount and quality of testing developers will carry out varies greatly. Putting aside any lack of enthusiasm for breaking their own code, other factors such as the architecture of the system, the quality of the test plan, if produced, and whether automated tools can be applied will influence the number of bugs remaining after system testing.

Many years ago I went to a short seminar about testing. It sounds boring but the managing director of the company leading the seminar was so enthusiastic about testing I came out enthused. He spoke in depth about a concept called the engineering V, where you have business requirements at the top of the V and development almost at the bottom. The design and development part of the project runs along the left side of the V, top to bottom and the testing part on the right hand side from the bottom to the top of the V. The idea was that you tested against the opposing specification, so unit and system testing would be against the technical design, user acceptance test against the business requirements and so on. The odd thing is that this concept is so clear in my mind over 15 years later but I can find no reference to it anywhere.

This concept does rely on top quality requirements and design documents being produced and test plans directly from these documents.

Personally I like the idea of being able to automatically test applications, so that the same tests can be easily applied against each build and release. Sometimes this consists of bespoke test harnesses testing software components, sometimes automated test tools attacking the entire application. I also favour having test plans for unit and system testing written as part of the technical design, with an indication of the plan’s successful completion forming part of the code
review.

Above all I value a user acceptance testing team that lives and breathes testing, but it’s important not to allow an “us and them” environment to exist between the development and test teams. I did hear a story about one company that attempted to improve the quality of its software by paying the test team a bonus for each bug found and the development team a bonus for each bug fixed. Needless to say the number of bugs found by the test team and fixed shot up dramatically helped by an “agreement” between the two departments, and the scheme was quickly dropped.