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.
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.
Often, programmers and testers have very different ideas of what quality means. They're not alone. People have been arguing about quality for hundreds of years and haven't gotten very far (see Pirsig's Zen and the Art of Motorcycle Maintenance). The solution isn't in finding a specific answer for all time, which is impossible. Quality is highly subjective and means something different from project to project. Instead of seeking out a single answer, leaders have to drive for collective agreement on quality for the current project, and avoid philosophical debates.
Smart teams work on defining quality early. Since they know that towards the end of the project they'll need test cases to find bugs and evaluate progress, they decide not to wait to the end to sort those things out. Decisions about quality can be made early on.
Test-driven development (TDD), a popular approach for bringing quality into the process earlier, makes testing and quality assurance an integral part of every function and feature design. Before the code is written, test cases--conditions that the software must satisfy before it can be released--are created that define the conditions the code is to achieve. Just as you'd be foolish to start driving your car without knowing where you're going, why write code before you have a goal in mind? (Unless of course you enjoy wandering around highways and code bases.)
The spirit of TDD applies to all types of work. If you define the characteristics of the end results early, and communicate them to others, the odds of success always go up. It separates the ends from the means, freeing everyone to use whatever skills they have to help the project achieve its goals.
In the history of warfare, one thing is clear. It's those in power that create the conditions that lead to war. Whether it's acting out of fear or refusing to compromise, leaders have the power to start and end conflicts. Testers and programmers are no different. If there's strife in the programming trenches, look to the leaders for the causes.
The relationship between the most senior programmer and most senior tester sets the tone for the rest of the organization. If they ignore, ridicule, or patronize the other, others will follow. Leaders define a model for behavior--both in terms of how work in that role should be done and in how people in other roles should be treated. This also applies to group managers. The behavior of person managing all of the programmers and testers will define the rules of behavior for everyone else in the organization.
To improve on relationships between testers and programmers, the respective leaders need to take responsibility for the situation, prioritizing it well against more technical kinds of work. Forwarding articles like this one around can help bring light to the problems. But real improvement can only come when leaders step forward, openly acknowledge the problem, and bring people in from both sides to create a collaborative plan for how things must change.
Scott Berkun is the best selling author of Confessions of a Public Speaker, The Myths of Innovation, and Making Things Happen. His work as a writer and public speaker have appeared in the The Washington Post, The New York Times, Wired Magazine, Fast Company, Forbes Magazine, and other media. His many popular essays and entertaining lectures can be found for free on his blog at Scott Berkun.
Return to the Mac DevCenter
Copyright © 2017 O'Reilly Media, Inc.