Across the Great Divide

[article]
The Language of Common Ground between Testers and Developers
Summary:
Many bemoan the strained relationship between testers and developers. But while we can't force testers and developers to see eye to eye on everything, we can reduce some of the tension by making simple changes in the way we communicate. Learn some great tips and tricks in this article.

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,

About the author

Susan Joslyn's picture Susan Joslyn

Susan Joslyn is a developer who advocates testing and quality processes. She is the author of PRC, a complete, integrated SCM tool for IBM's U2 & Raining Data's Pick/D3 software development environments. She speaks often at conferences on topics ranging from development techniques to test management. The particular niche industry of software developers that she works with largely comprises creative, undisciplined, non-computer-science folk, for whom structure is “the enemy.” She is the lone advocate for testing and quality process among them, and an “ambassador” for the developers at the testing and software quality conferences she attends.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!