Anyone whose job is to pass judgment on another's work must have the authority to do so. Without authority, their findings will be ignored and their work will be without effect.

Many software testers establish their authority on the basis of their correctness—and ultimately on their ability to be more correct than the programmers whose work they judge. Their adherence to standards and requirements, the thoroughness of their work, and their attention to detail give them the authority that compels programmers to pay attention to their bug reports. This is a common approach, and it certainly has its place. But this approach can take its toll on testers. It's not easy to maintain perfection.

Other testers have found a different approach that doesn't require perfection and indeed that can often be more effective, especially in fast-paced development organizations.

When requirements are changing or incomplete, it can be very difficult to establish authority based on correctness. In these situations, effective testers need to model flexibility, honest concern, and a willingness to accept criticism. Correctness still has its place, but these testers are not trying to prove that they are more correct than the programmers. They accept criticism, withdraw bug reports when fair explanations have been given, and engage programmers.

They establish their authority on the basis of their concern. They are concerned that the customers and users will get software that they'll be pleased with. And they are concerned with helping the programmers meet that goal.

Expressing Concern-Based Authority
Fast-paced development requires programmers to share incomplete work. This leaves them vulnerable, and to be an effective tester, you'll have to show some concern for them. They know their work isn't 100 percent correct-your testing really needs to determine whether it's heading in the right direction. It's hard for your testing to be 100 percent correct in such situations as well. So being open to discuss how the software should be working benefits everybody.

All testers know that both correctness and concern are important. The distinction I'm drawing is in how they establish their authority. Those who base it on correctness need to establish that they are more correct than those they are judging. This can lead to a contentious dynamic. Programmers are typically reluctant to concede on these grounds. They'll resist the implication that they aren't doing a good job. They'll criticize spelling errors in bug reports. They'll try to throw blame back on the testers.

On the other hand, testers who base their authority on concern don't have to prove that they're more correct or that they care more than programmers care. Testers who think the software isn't going to please the customer still need to explain why. And programmers need to give their perspective. Is there a disagreement of principle or priority? Are technical issues preventing an ideal solution? Conflicts of concern just need to be worked out.

Authority based solely on correctness leads individuals to strive for individual perfection—a precarious goal. Authority based on concern allows us to accept the possibility for error that lies within each of us. Testers who operate on this basis can model how to take criticism well. We all make mistakes. Effective teams use constructive criticism of works-in-progress to improve the work.What I like best about basing authority on concern is that it allows a tester to retreat from a position without establishing precedent. The tester can decide that the concern expressed in a bug report has been heard and then withdraw it because there are more important issues for everyone to deal with right now. The concern still exists, and may be expressed again in a similar situation if prudent.

Testers who base their authority on correctness don't have this flexibility. When their authority is based on being right, they have to defend every bug report they write. They get a reputation for being argumentative, unyielding, and unable to differentiate critical issues from minor ones.

Combining Approaches
Best is to have the ability to base your authority by either means. Start by focusing on concern. Establish collaborative relationships with the programmers. Understand their concerns and use your testing to determine where their weaknesses are. Most programmers will welcome this kind of engagement, will realize that you're just trying to make their work look better, and will appreciate your perspective.

But some will still resist. And for these you'll have to double-check your results and standards so that you can establish whether their work is correct or not. Does it stand up to the claims that they've made about it? If they are going to put up obstacles, you're going to have to overcome the obstacle course.

So how do you establish your authority? What kind of reaction do you get from the programmers whose code you test? Do you think you could benefit from an approach that balances correctness with concern?