Communication is one of the most under appreciated skills for software development teams, but it can mean the difference between success and failure. There is nowhere this is more apparent in most organizations than communication between QA and developers. Often times, developers work on features independently of QA, throw the code ‘over the wall’, and only hear back from QA when a bug is found that needs to be fixed.
While this approach works great in traditional waterfall development models, the rise of Agile methodologies necessitates a much tighter feedback loop. Modern QA and developers must work hand-in-hand during each sprint to both develop and test a feature, which enables the organization to respond to changes immediately and quickly iterate midstream. This requires effective communication and a merger of the two teams.
Bring the Teams Together
The first step in improving communication is getting QA and development teams together. In some organizations, the two teams can become rivals since QA members seek to find problems with their work and may feel that their job performance is related to the number of bugs that they identify. This mentality must be shifted to that of a single team with each party playing a valuable role in ensuring that high-quality software is shipped every time.
Group activities and team building exercises that incorporate both groups can be helpful in building a healthy culture, but the best way to bring the team together is through shared roles. For example, you may want to consider letting QA members learn more about development through pair programming and/or let developers participate in writing and running test. This helps create a better understanding of each responsibility.
You may also want to reevaluate how you evaluate performance for both QA members and developers. Developers shouldn’t necessarily be penalized for the number of bugs they create or fix and QA members shouldn’t be rewarded based on the number of bugs that they find. A better approach is rewarding both teams for shipping bug-free software on time and quickly addressing any problems that may arise along the way without pointing fingers.
Redefining the QA Process
QA members and developers should collaborate at the beginning of a sprint when a new feature is being discussed. Rather than jumping immediately into the code, the two groups should discuss how each feature is going to be broken up into parts and what exactly is going to be tested. Developers can then write the code that passes those tests one-at-a-time rather than delivering an entire feature at the end of a sprint to be tested all at once.
Rather than using bug tracking software or email chains as a proxy for in-person meetings, QA and development teams should be located in close proximity to each other or be on the same instant messaging channels (e.g. Slack channels). They should also use the same burndown charts or wallboards to show when large backlogs of QA work develop towards the end of a sprint. This way, you can address any problems before they become a major concern.
The benefits of this approach quickly become apparent: Without these processes in place, QA may find a bug in a prior sprint that requires a major change right away. Pulling developers off of the current sprint to fix it might set back the timeline and pull the launch off course. By contrast, incorporating this would enable a QA issue to be addressed mid-sprint before any software is shipping, which helps avoid problems and keeps the timeline on track.
Communicating with Developers
QA members should also keep several things in mind when communicating with developers to ensure that everyone is effectively working toward the same goal. Often times, ineffective bug reports can lead to wasted time and frustration from both parties, which means that it’s important to invest enough time in being clear and concise. It may even be a good idea to discuss some bug reports in person or via screen sharing to be completely clear.
Some tips for communicating bugs include:
- Be Specific – You should include a clear summary of what the problem is and include every single step to reproduce the problem with screenshots.
- Remain Focused – You should only report one problem at a time and stick to what matters. If there are multiple issues, split them into separate bug reports.
- Take Your Time – You should take your time when writing these reports. After all, if something is unclear, you’re wasting both your time and the developer’s time.
It’s also important to remain objective when communicating with developers. Don’t use words like “obviously” or “clearly” since it may be offensive to developers that may not find it “obvious” or “clear”. And, be sure to carefully lay out how a problem is arrived at and reproduced rather than making any assumptions. The developer working on the bug may not have written the original code and may have limited background information.
Conclusion
QA and development teams have a tenuous history in many organizations, but Agile methodologies have forced them to work together more cohesively. If you don’t already integrate QA members and developers into a single cohesive team, it may be a good idea to have them work together on sprints and even share roles to be more effective. These efforts can pay big dividends over time by shipping higher quality code more quickly.
At the same time, it’s important for QA members to effectively communicate with developers to ensure that there is no time wasted trying to interpret bug reports and minimal risk of accidentally offending someone. By keeping these tips in mind, you can quickly convey software bugs and avoid any potential problems over time. And an effective QA and development team helps ensure that software is shipped quickly with minimal issues.