How to End Wars Between Testers and Programmersby Scott Berkun, author of The Art of Project Management
There's a natural conflict between testers and programmers because of the difference in perspective each role has. In the simple view, programmers are centered on creation: they make things that didn't exist before. Like most creators, programmers have a natural optimism about making new things and solving problems. (The programmer's motto: "Given enough time, I can build anything!")
On the other hand, testers are centered on inquiry and skepticism. Testers have doubts about all engineered things. They use their knowledge to bring light to the dark corners of decisions others are ignorant of or in denial about. (The tester's motto: "Everything has flaws and I can prove it!")
While it's possible to bring these two forces, optimism and skepticism, together and create a synergy of talents that makes for better software, it's rare that this happens. Often individuals stay polarized in a narrow programmer/tester, optimist/pessimist mindset, never stepping back to consider the advantages of using both points of view. The code becomes the victim of the team's politics and is thrown back and forth over the dividing wall. By the time the project is over, the team has spent more time arguing over how to do the work than actually doing it.
The best way to end struggles between programmers and testers is to redefine the goals of the work so that their roles can be collaborative, not adversarial. While it's true there are many different ways to organize programming teams, including some where there are no dedicated testers (some argue that a true software engineer is a master of quality assurance), this article assumes that you fall into the majority of mid- and large-sized development teams with some kind of dedicated test or quality assurance role.
Matching Responsibility with Authority
One challenge for testers, or quality assurance types, is that they are often held accountable for the quality of what is made, despite having little influence over how the software was designed. In the worst cases, the programming team is several weeks ahead of the test team, writing much code before the test team is able to get involved. Instead of quality assurance, something that implies confidence ("I assure you the quality will be high"), they are really doing quality patchwork ("I'll get the quality as high as I can given what you've handed to me"). Bringing testing in late with few resources makes quality assurance, in the true definition of the term, impossible.
The simplest way to minimize strife between test and development is to match the test team with enough authority to live up to its job title. Either they should be granted enough power to participate in, or give feedback on, the early design of the software, or the limits of their role should be acknowledged openly. But if you keep a test team stuck in between, with high responsibility but little or no power, they are bound to fail in ways that disrupt the entire project. I'm not advocating that testers should rule the world. I'm simply saying their responsibility should be roughly equivalent to their authority.
The best development teams I've ever seen figured out their roles early on. Testers, programmers, and anyone else spoke up early about what they felt was important for the project and how their expertise should be used. If the team had good leaders, they'd negotiate agreements about which kinds of issues would tend to be decided by programmers, which ones would tend to be decided by testers, and which would be decided collaboratively by both (or more) parties.
If you want people to work collaboratively, you must provide time for them to build relationships with each other. It's impossible to share important things with people you don't know very well. (Imagine trying to explain to your mailman your deepest, darkest secret fears. It doesn't work. And worse, you might stop getting your mail.) Given this fact of human nature, it's not surprising that many programmers resent the involvement of testers. If, a month into a project, a tester shows up looking for flaws, they will meet resistance. The source of the programmer's pride, the quality of their code, is being challenged by a complete outsider and the tester will be treated as a threat, not an ally.
Instead, programmers and testers should be matched from day one. They'll meet and discuss what they expect from each other, and what activities they each expect the other to do. They'll use any project goals or work item lists to prioritize their efforts and help make decisions that impact each other. There will be every opportunity for the programmer to see the tester as a way to help improve the quality of their work on a daily basis, and increase their pride. The tester won't be an outsider looking for flaws and handing out demerits. ("Bad programmer, bad!") Instead, they'll be an insider, a collaborator, intimate enough with the programmer's work to help in ways no one else can.
And perhaps most important of all, building programmer/tester relationships early creates the bonds needed for the project to survive tough times. When problems arise late in the project and stress is high, people will have a history of trust in each other. They will respond to pressure and new challenges by looking for solutions instead of pointing fingers.
Pages: 1, 2