Create Quality

June 7, 2007

Recently I was at an event from the company I worked for. The topic of the event was: “Creat Quality”

Creating quality is something that is very much at the core of agile development processes and as a programmer is very important to me. My expectations were very high.

After the event I was disappointed. The talks were filled with waterfall-centered thoughts and how a testmanager can help create quality in that environment.

But as long as you think in waterfall, testing will always come after implementation and way after design. And I mean that in every possible way:

Testers opinion count less
Testers (often) get paid less
Generally, testers are less important because they “only use the software and report bugs”

No amount of reviews, checklists, metrics will change that. What you have to change is the way software is created. Where the tester, the programmer, the project manager and the customer representativ/analyst/product manager are all equals.

You can’t reach this in a waterfall, because by definition these roles don’t work together - they work after each other. You can try to circumvent waterfall by including the testmanager early - but he’ll always be “out of his phase”. This means, he’ll be tolerated and if he steps too far, the “phase owner” (*) won’t be happy.

I was very surprised that agile methods didn’t find more friends among Testers (at least the ones I know). But I think I understand now:

If your company really wants to create quality software, it doesn’t need more testers.

What agile methods promise seems to somehow make the testers job disappear. There is no testing phase, so where are the testers? How should it be possible to develop software with few defects without a test phase?

Yes. Agile Methods kill the test phase. But it needs testers and it requires them from day 1. Automated tests are important in XP and in many other agile methods. Customers and programmers mostly think about the “happy path”. Somebody has to help them think of missing tests. Somebody has to help them think of ways to test complicated things automatically. Somebody has to let them know that the software created in the last iteration wasn’t up to the quality standards the team wants to deliver. Act on that information and help fix the problem.


(*) I use “phase owner” as the person who has to say how one phase is run. This may be the Senior Designer for the Design Phase or a Chief Programmer for implementation. Whoever, don’t go to their office and try to tell them how to run the show.

Posted by Jerome Mueller

Leave a Reply