Are developers and testers locked in an eternal feud? As the discipline of testing becomes more defined, so do the battle lines, it seems. Why does it seem that the more mature the process of software development becomes, the less "mature" the rivalry between the testers and the developers?
Some people are genetically predisposed to be developers. And some are likewise predisposed to testing. Those are differences that can be explored, perhaps better understood, but not "fixed." But when it comes to the emotional baggage that each side brings to their profession, well, this is where the discussion can move from rhetorical to practical. The relationship between testers and developers, just like any other emotionally charged relationship, is fraught with misunderstanding and lack of communication. Fortunately, this makes the first step toward correcting the problem both simple and extremely effective!
How do we communicate more effectively? By having a common lexicon-a common framework of experience with a language that everyone understands. Remember Humpty Dumpty, in Through the Looking Glass, saying, "(A word) means what I choose it to mean-neither more nor less"? Well, that only works in fiction. Back at the office, we have to decide together to accept the meaning of our words.
Testers and quality professionals have a relatively newly established language for discussing issues of software quality. Unfortunately, while it is creating a great common ground for those professionals to speak to each other, it can leave the developers out of the loop. That can be dangerous for two reasons. First, a developer left to discern or invent a meaning may not approximate the intended meaning. Second, some of the words and phrases being used stir a natural fight-or-flight response in a developer.
Here are some proposed steps that can help.
Define and explain terms. Since testers mean something very specific-formal, documented-with their phrases, it will help a great deal if those phrases and words are explained specifically the first few times they are used with the development team. Never assume that the rest of the team knows what you mean by "black box testing." This sounds simple, but if you ask your developers what they think "unit testing" and "system testing" are, you may be surprised by the variety of interpretations.
Replace hostile or "hot-button" language. Some words are emotionally charged. The simplest, most obvious, is the word "test" itself. When you say that you are going to "test" someone else's work, it suggests that you have some authority or dominance over that person. (This may be why testers are held down so firmly-but that's another discussion.) It also suggests that you expect something to fail. (Now don't argue. It feels that way to the developer.) It may be truly worthwhile to find a different word to replace "test" in your discussions with developers. One good replacement word is "validate." When you propose to validate something, it implies that you expect to prove that it works-not to prove that it doesn't.
Some other words that can have negative emotional impact to the developer are "bug," "problem," "fix," and "broken." It's better to decide together on neutral words, such as "issue," "report," "request"...whatever works within your organization. But think neutral! Likewise, when a "bug" isn't fixed the first time through, careful selection of the phrase that will come to mean "re-work" or "bounce" can make a big difference. "Secondary evaluation"? (Then again, maybe some aggressiveness in the language is warranted at that point-don't pander too much!)
Tailor your lexicon to fit the team. To introduce fun and team spirit while creating a common ground for communication, think about what the developers are "into" and consider a theme. Are they Trekkies? Into drag racing? Fishing? Techno-junque? Is there a favorite classic (Star Wars, The Hobbit, Xanth) that has its own language? The team of testers and developers can define words and phrases from that "world," define their specific meaning to the task of creating quality software together...and then communicate in a way that is neutral and fun, in a language that belongs to both sides.
Here's an example. In a shop where drag racing aficionados are at work, a unit test becomes a demo run. A system test becomes initial trials. Conversations may be had regarding performance, pit times, and whether a two-tire or four-tire change is required.
The important thing is to recognize the importance of clear, effective communication, and the impact of unclear, emotionally charged language. It's not a panacea, but many of our timeworn feudal difficulties can be alleviated by some attention to the language that we use.
