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:
- Because of a trend toward more agile software development
, testers are in contact with developers earlier and more often
- 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
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.
2 comments. Add Comment.:
Nice Analysis..!
I am a tester but I can understand that it must be difficult for a developer to have their work critqued by someone who has not contributed a line of code to the product.
There is an old joke that goes: what do you call an actor who cannot act? a:- a critic.
If the tester does not take responsibility for maintaining a good relationship with the developer, then a project can get into serious trouble very early on.
In order to maintain a good relationship with a developer, a tester must:
*Convince the developer that they have software quality as their first and foremost priority (consulting with the developer on the test strategy and test cases is a good way to start this process)
*Communicate with the developer constantly - for instance, allow them a heads up on any P1/P2 defects found before they are logged for project visibility. This gives the developer time to plan the fix approach so again the project consult them, they have all the answers ready instead of being put on the spot.
*Show intelligence.
Know the product functional and technical specs. Make notes when you ask questions so you do not ask the same questions over and over.
Constantly log reproducable defects with clear regression steps and an analysis of the defect impact if applicable.
*Show loyalty.
Do not let the developer down in front of other project members. If they have just balled you out for logging a defect that is really a feature, do not retailate by pouring scorn on their coding ability to their manager.
Of course, this is very simplistic and barely scrapes the surface of what has to be done to keep the dev/test relationship in good stead. However, I do believe it is a good start.
Post a Comment