Tuesday, January 12, 2010

Understanding The Differences Between Testers And Developers

Are testers from Venus and developers from Mars? In an ACM article titled An Exploratory Research Study on Interpersonal Conflict between Developers and Testers in Software Development, the authors look at the difference between testers and developers.
As stated in the article, the goal is to better understand the differences between thse two actors in order to produce better software. The authors' call to action is based on two reasons:

  1. Because of a trend toward more agile software development, testers are in contact with developers earlier and more often
  2. Conflict can have negative consequences not only in relation to the end product but also in relation to the job satisfaction of both developers and tester
This paper points to studies that clearly separate testers from developers in terms of their goals: developers seek to maximize efficiency while testers are all about effectiveness. Developers seek to do get their work done with the least effort while testers seek the highest quality.  Those are clearly different goals that can easily create conflict if each group sub-optimizes. Unless upper management reconciles these different goals and helps align them to reach the broader objective of the company, failure may ensue.



In addition to understanding the goals of each actor, managers need to understand and work with the differences between testers in terms of what makes them good at what they do.  The authors point to a list of the twelve traits that make good testers and developers (Pettichord, 2000):

If these are truly the traits that make for good testers and developers, then you can see why those bug review meetings tend to be a little tense at times, especially when one group or the other has to justify fixing or not fixing a bug.  Unless management understands the differences between the respective goals and attributes of developers and testers, and fails to effectively manage the natural conflict, the risk of failing will always be high.

So how do you effectively manage the conflict? I suggest taking the list above and adding another column with notes on how to address the conflict when it arises.  For example, what do you say when a tester points out a bug (what's observed) and the developer say it's a feature (how it's designed)? Do you blow it off and agree with the developer or do you take the issue on as something that needs to be resolved either as an issue with the design or the documentation? By thinking through examples for each conflicting pair of attributes, and writing down examples and responses, you'll be able to better manage the conflict.

You can read the entire article here.

0 comments:

Post a Comment