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 treat them as test holes and blame the QA team. Review and see if in fact the correct requirements were articulated or if the code was written and unit tested properly by the development team.
As a manager, identify if tools are causing communication issues or overhead. Are your developer and testers using different systems to track code changes or log defects? Do testers know when features are being completed, when bugs are being fixed? If not, it means they could be spending a lot of time and effort just trying to stay abreast of what is going on. This will clearly cause communication issues like the example I had mentioned earlier, where a developer checks in a code that a tester only finds weeks later, when either some of his tests break or a user complains. Ensuring that teams have the right tools should be high on the managers list as one of the foundations for building better communication and more productive teams.
If team members can physically be present at one location, that can also help open up communication, but where that is not feasible, doing frequent cross functional meetings to raise visibility of issues in a timely manner will also help.
Sticky ToolLook: When there has been a breakdown in communication, what first steps do you recommend for getting things back on track?
Amit Chopra: Focus on understanding the root cause of the issue. It will be critical to get the representatives from test and development teams in a room to raise the right issues and understand why communication is breaking down. You may identify one or many underlying causes. Some may be related to work styles, team culture, or organization structure, while others may be results of disparate tools used by these teams or just a lack of common understanding of the scenario. Each of these issues can be addressed as needed by putting the right team structure and processes in place or at least ensuring they have the right tools to help alleviate some of the communication challenges.
Break the artificial walls between your testers and developers and you should be off to a great start in shipping a high quality product to your customer.
