“My testers currently report to the development manager. I’m thinking about moving them into a separate reporting stream with their own manager. That way, they’ll have more clout, and the project managers will have to listen to their concerns.”

Almost since the day designated testers appeared in software development, there has been debate about whether they need to be independent, and just what “tester independence” means. In the past ten years or so, there has been a trend away from isolating testers in their own organization, separated from the programmers. I believe that’s a healthy way forward for our software projects, but it does still leave the following questions open:

• Does a tester need to be independent to be effective?
• What do we mean by “independent”?

Where Do Testers Fit in Software Development?

Our understanding of where testers fit has evolved, most recently through the agile movement’s emphasis on cross-functional teams and collaboration. It used to be common for organizations to expect their testers to hold themselves aloof from what the programmers were doing. This was typically based on a belief that you would only get good testing from “independent” testers—that too-close collaboration would somehow compromise that independence. To foster test independence, those organizations removed their testers from the programmers’ sphere of influence, giving them a reporting stream of their own.

Organizational Independence

At the time, creating organizational independence seemed like a good idea. Managers feared that, without it, testers’ findings would be suppressed or overridden by the development leads they reported to. Testers wanted it, too, not least because they believed that having their own organization would bestow on them the credibility and legitimacy they often found themselves fighting for on projects led by programmer managers or project managers who had been programmers.

Some of those benefits were realized, but I’m not alone in believing that they were frequently outweighed by the negative unintended consequences. Too often, testers came to see themselves as the sole champions of quality in their organizations. Instead of working with the programmers and talking with them about what they were building, testers sat at their desks waiting for frozen requirements to come to them and then didn’t start testing until they got frozen systems. Many testers became gatekeepers—effectively, arbiters of quality—instead of development partners. In some organizations, the testers came to be viewed as obstacles, getting in the way of the development process while adding no real value. Rather than enhancing testers’ credibility, the combination of that view and those tester behaviors sabotaged it.

I’m describing all this as if it were safely in the past, when, in reality, it is still the situation in a lot of places. And, of course, there are many contributing factors. But organizational separation has often reinforced a dysfunctional relationship between testers and programmers, even where it wasn’t the root cause.

All of this goes through my mind when I hear a manager talk about wanting to give her testers “more clout.”

What’s the Real Problem?

First, what problem is that manager trying to solve? She believes that the project managers aren’t listening to the testers and giving their concerns due consideration. Why is that happening?

Is the real issue that the testers lack clout, or do they lack credibility? If it’s the latter, it’s doubtful that isolating the testers in their own organization would make project managers take them more seriously, even with their own manager advocating for them. It might well backfire and fuel antagonism.

If the issue is low credibility, why is that? Perhaps the testers are perceived as always “crying wolf” about minor problems. Or, perhaps they don’t have the skills needed to test adequately, and they repeatedly miss important bugs. Or maybe they’re highly skilled at testing but need help with their communication skills.

It’s always essential to ask if testers are afraid to defend the information they’re paid to uncover about the software. If managers don’t make it obvious that they value what testers have to say, testers won’t feel supported.

What signals does management send the project managers? It could be that the testers convey credible information, but the project managers feel management pressure to deliver on time regardless of product problems. Does management reward project managers for delivering quality products or only on-time projects?

If testers’ concerns are being ignored, it’s likely that several cultural factors are in play, and it will be futile to try and solve the problem without addressing the culture. Simply reorganizing the teams won’t do that—and it won’t give the testers any more clout.

The Truly Independent Tester

If we don’t believe that separate test organizations are the solution, does that mean the concept of tester independence is no longer important?

I think it is important. A tester needs to be both a full development partner and an independent observer—able to dive in and collaborate, and yet maintain his or her identity as a tester. That can be an extraordinarily difficult balancing act for anyone. If the whole culture doesn’t support it, the tester will fall off the wire.

Not everyone wants to hear what a tester has uncovered. Sometimes the tester’s information could delay a release and cause problems for management. And sometimes, not listening to that information results in bigger and more expensive problems.

It’s possible that a separate reporting stream for testers might still be useful in some circumstances. By itself, though, organizational independence will not guarantee that testers can uncover and communicate their information without fear to managers who will listen.

Instead, I suggest that tester independence is a state of mind—one that every healthy software development culture encourages and nurtures.