In this Sticky ToolLook interview, Microsoft senior program manager Amit Chopra takes a look at some of the common communication breakdowns between QA and development teams and offers suggestions for avoiding or repairing those situations.
Sticky ToolLook: What are some of the common breakdowns in communication between QA and development teams?
Amit Chopra: It is fairly common to hear the phrase “Developers are from Mars, testers are from Venus.” This statement is just a reflection of challenges around developer-tester communication that most projects deal with.
Developers feel frustrated when defects show up for them to fix and they are left wondering why the tester is testing this. What’s the customer scenario? Or, they get defects they are unable to reproduce due to incorrect steps, or they are unsure if the steps that the tester claimed to have run are actually what he did.
Testers, on the other hand, are frustrated when most of their bugs come back as “no-repro”—classified as needing more information or “by design” because that’s how the developer thought it should work. It can be frustrating when they have to hold their test environment if the developer is on vacation for the next few days. They may also get frustrated when developers make code changes and the testers can’t understand why, or they find out about issues late in the game resulting in broken tests, regression, and, worst of all, poorly tested code reaching the customer.
Lack of common understanding, not having visibility into what the other team is doing, and the fact that many teams are now geographically separated can add to communication gaps resulting in delayed and poor-quality projects.
Sticky ToolLook: From the outside, it’s easy to look at an organization and say that everyone’s working toward the same goal: building the best software possible. But, that’s not always so readily apparent from within. What tips do you suggest for taking QA and development from an “us vs. them” mentality to “all of us working together”?
Amit Chopra: An “us vs. them” mentality will certainly do more harm than good to your project. If you have observed this phenomenon, focus on defining a common set of goals and accountability measures. Have testers and developers interact early and often. It is not uncommon to find test teams working as a center of excellence, serving many development teams. As code gets done, it is “thrown over the wall” to test. When issues are found, each group simply challenges the credibility of the other team.
One approach to address this is to involve the test team when the development team is writing the design documents and have the development team get involved in the review and creation of test plan. This will certainly help both teams understand and appreciate what each other is doing and also give them the feeling of being involved and a sense of co-ownership in the outcomes.
Using a toolset that helps developers and testers communicate in a common frame of reference will certainly help catalyze this process. More often than not, developers don’t understand the tools and frameworks that testers use, while testers are oblivious of the code changes that developers make and the processes they use. Giving each developer and tester an understanding of what the other does and how will help bridge this gap.
Sticky ToolLook: How can managers work with their teams to build that communication from the start?
Amit Chopra: Managers should help focus on common goals and scenarios. Unless quality is a collective responsibility, there will be finger pointing and blame games that tend to lessen the overall productivity of the team.
For example, don’t just make quality a problem of the QA team; everyone on the project should be accountable for it. When bugs are found late in the project, don’t just