Bridging the Gap: Collaboration Between Developers and QA
The relationship between a developer and the QA team can be compared to a quickstep dance in the context of modern software development. When successfully implemented, this process is ideal for the development of sound, high-quality applications.
However, when the steps are out of sync, this causes friction and the output is a poor-quality product. In this article, we will discover how to effectively narrow the distance between developers and QA to create a more collaborative relationship.
The Historical Divide
At the time when people followed the waterfall method, developers and QA teams acted independently of one another. Developers work on creating features, whereas QA specialists are supposed to discover defects in these features after the development life cycle. This often created a divided mentality between the two main parties of ‘us’ and ‘them.’ Developers may perceive that QA hinders their progress, while on the other hand, QA may consider developers less serious about the project.
I came across some outsourcing companies that used to promote outsourced testing. Can you believe they still exist? I found several companies that are still offering this service.
In that old approach during the testing phase, QA identifies issues and passes the feature to the developers for corrections. This can cause tension and prolonged communication under strict time constraints needed to complete a project.
The Agile Shift
Agile development methodologies called for more cooperation between the development and QA teams. When using Agile, both teams are involved from the beginning of the project. This keeps one from having to go back over the other’s work which takes time and may delay the project.
You can read more about the Shift left approach from my previous article.
For example, in an Agile organization like Spotify, developers and QA are usually in one team, and everyone is in small teams. The described setup ensures feedback and fast prototyping, which enhances both the quality and speed of development.
Check this link to learn about the Spotify model.
Building Empathy and Understanding
There is no better way to close the gap between developers and QA than by cultivating empathy. When each team is aware of the difficulties the other faces and the kind of pressure they are under, it becomes easy for the two to collaborate.
An example of this approach in practice can be observed at LinkedIn. LinkedIn provides incentives for developers to attend meetings known as the bug bash, where everyone, including QA, fixes bugs. This not only makes the developers realize how much effort is invested by QA but also helps the QA to realize how much trouble the developers go through.
I found this nice article about “Bug Bash” by Mohammad Faisal Khatri.
Communication and Collaboration Tools
One of the biggest components that facilitates collaboration is communication. Some of the useful tools that can help developers and QA in better communication and project management are MS Teams, Slack, bug tracking tool (JIRA), Agile board and Confluence. These tools assist in monitoring progress, passing information and guaranteeing that everyone is in harmony.
For example, at Atlassian, the company that adopted JIRA, developers and QA utilize JIRA to create issues and manage them. It is useful for tracking bugs, features and improvements to align the two teams’ goals and objectives.
Integrating QA into the Development Process
One of the ways of minimizing the gap is by having the QA as part of the development life cycle. This means for instance calling in the QA team right from the planning phase and having them participate with developers right from the developmental phase.
One example is Google, where QA engineers, referred to as Software Engineers in Tests (SETs), are embedded within development teams. They are the ones who write the test code, create the testing frameworks and make testing a part of the development process rather than an add-on.
Shared Goals and Metrics
Developers and QA should have the same goals and metrics in order to achieve better collaboration. Bug tracking no longer has to be considered a failure but can be looked at as a way to improve. It can be organized around goals such as decreasing the number of post-release defects or increasing user satisfaction.
Continuous Learning and Improvement
Finally, there is a need to encourage learning culture and organizational improvement. Scrum meetings where the developers tell what was right and wrong with the QA and vice versa can bring important lessons and make the process better.
In Amazon, “Correction of Errors” documents are used to review any failure and includes both developers and QA. This practice enables the mistakes to be rectified and not repeated because it fosters change.
Correction of Errors document by AWS
Conclusion
One cannot turn the screw between the developers and the QA team the other way around instantly. The accomplishment of the goals of the systemic approach requires collaboration in building empathy, improving communication, connecting processes, aligning goals, and embracing learning. Therefore, the steps provided above can be employed in order to ensure that both the developers and the QA work together and deliver quality software.
As a final work, it’s about recognizing that both teams have the same goal to create reliable and effective software that can meet the users’ needs and can be effective in the real world. The idea that the developers and the QA can work hand in hand is not only good for the software but also for the team.
