Most testers are committed to helping produce better software. That's a good thing. But when a tester takes on the role of "quality police," good intentions can turn ugly. The quality police don't just report the bugs. They appoint themselves judge and jury, ready to dispense justice according to their own convictions of what programmers should be doing. And the project is likely to suffer for it.
Software testers often fall into the role of being the quality police. They enforce quality standards, identify programmers who are not following procedures, and do what they can to punish programmers whom they feel are producing inferior work. My view is that the quality police role traps testers into being less effective as testers. And it's more likely to undermine the project by discouraging communication, reducing trust, and causing delays.
A software tester's job is to test software, find bugs, and report them so that they can be fixed. An effective software tester focuses on the software product itself and gathers empirical information regarding what it does and doesn't do. This is a big job all by itself. The challenge is to provide accurate, comprehensive, and timely information, so managers can make informed decisions.
However, many testers take on additional "responsibilities." They harangue programmers for shoddy work or for not following proper procedures. Or they try to mandate how programmers should operate. Or they snipe at the design instead of finding bugs. These testers may refuse to test builds that don't have sufficient documentation or refuse to research bugs that shouldn't have been there in the first place. They think that programmers require discipline and are determined to give it to them. I call these people the quality police.
Some testers adopt the attitudes of the quality police on their own initiative. Others do so at the prompting of their managers or the advice of authors and consultants. Let's look at some of the beliefs that can lead to trouble.
Testing Is Quality Assurance
Like most testing groups, yours may be titled "quality assurance." Naturally enough, this may lead you to think that you are responsible for the quality of the software. So you need to do whatever is necessary to ensure that the product is high quality. Don't let the programmers get away with practices that risk introducing bugs. Don't let them cut corners or avoid "best practices."
But this is unreasonable. You can't be responsible for the work of other people you don't manage. At its worst, this sets up a dynamic where the testers are the "quality assurance" group, intent on avoiding bugs regardless of schedule, and the programmers are the "schedule assurance" group, intent on meeting a date regardless of quality. It's a recipe for disaster.
I advise testers to avoid the "quality assurance" label. And I advise managers not to expect their testers to "assure quality." If managers truly want an independent group to audit the work of the programmers, this group should be separate from testing. (It might also audit the tester's work.) Let the testers focus on the product, not the people. And let everyone take responsibility for the quality of their own work.
Programmers Need Discipline
If you're seeing lots of bugs, it's obvious that the programmers could do a better job. They should be unit testing, they should be holding formal code inspections, they should be defining requirements up front, they should be better managed—there's a long list of development practices that they may not be doing or not doing correctly. It's clear to you that the programmers don't know the right way to do their job, or they know, but are taking irresponsible shortcuts anyway. As the quality advocate, you have to do something about it.
It's easy to think this way. It's particularly easy when you've seen your pet development practice used elsewhere with good effect. Indeed, it's easy to get sanctimonious. Why won't they do things right? But wait. If you are convinced that you know how to run development, then you need to get a position as a project manager. Don't try to manage the project from the sidelines. And consider whether there may be factors that you're unaware of. But don't be a shadow project manager, cajoling programmers and project-leads to do things your way. You'll sow dissention and get a reputation for second-guessing. And you won't make the project go any better.The Programmers Are the Ones with the Problems
How can you do a good job testing when the programmers don't follow the plan? If you've made the mistake of signing on to an impossible task, like ensuring that there are no bugs, then you may be particularly motivated to find a way to focus management attention on the programmers' problems. By policing the programmers, you deflect attention from the shortcomings of your own work.
This happens all too often. Frankly, testers who lack ability or who haven't kept up on software trends seem to find a particular appeal in the quality police role. And they can get away with it in organizations with a lot of blaming. It's easy to quote standards and criticize people for not following them.
In fact, there are enough of these people that they can give all testers a reputation for being useless busybodies. By avoiding the quality police role, you'll help prevent programmers and managers from confusing you with them.
Good testing depends on getting clear information from programmers about their understandings of customer expectations (requirements) and the intentions of their code (design). It's hard enough to get this when you have a cooperative relationship. As soon as the programmers realize you plan to use their working documents to find fault with their work habits and create trouble for them, they're going to cut off the communication. They'll share less of what they have and will be less inclined to discuss it. The testing will suffer. It will be harder to plan and is more likely to be misguided.
Cooperative relationships between testers and programmers are key to rapid testing. But the quality police make this unlikely. By valuing the purity of independence over the effectiveness of engagement, they stretch out schedules and frustrate development.
Don't become the quality police. Don't be fooled into thinking that you know better how programmers should be managed. Even if things are screwed up, realize that the project is better off if you focus on finding bugs and letting others take it from there. If you see problems, figure out what kinds of bugs they'll lead to and look for them. But save your recommendations for how programmers ought to develop until you are asked.
I thank Cem Kaner, Brian Marick, James Bach, and John Jiang for recent discussions on this topic.
