The Keys to Healthy Dev-QA Relationship
Any successful software project requires two things: quality developers and quality testing resources. Even the best developers will make mistakes, and it’s critical to have a team on hand to find bugs before users have a chance to. However, given that the nature of the QA role is to find issues in the developers’ work, it’s no surprise that there can often be friction between the two groups. Keeping this relationship healthy is of paramount importance to create an open, efficient, and friendly work environment that can help ensure the success of a project.
Maintaining a healthy relationship, though, is about more than being respectful and patient. Read on to learn how to prepare your development process for success.
Communication is Everything
It should come as no surprise that effective communication is critical to a fruitful dev-QA relationship, but unfortunately, it’s a lot easier to say a project will prioritize communication than it is to actually do so. Fortunately, there are a few concrete steps you can take to assure that you’re not the victim of the type of communication breakdowns that have sunk so many teams in the past.
Avoid the “Telephone Game”
In general, the more planning that goes into a project, the more likely it is to succeed, and that maxim applies to the dev-QA relationship as well. Make sure that you’re including resources from business, development, and QA teams in all important planning and requirements meetings. Many businesses fear it is a waste of QA time to involve them so early in the process, but in fact we have found in our projects that the opposite is true. The more QA is exposed to the planning for development, the better they will understand the goals and desired results of development, leaving them better prepared to test the implementation.
Write It Down!
Likewise, establishing agreed-upon documentation early in the process can reduce disagreements later on. The entire team should work together to define expected behaviors, acceptance criteria, methods of testing, and how to communicate when observed behavior doesn’t align. This will help avoid ambiguity, scope creep and remove gaps between the teams, which are almost always the source when serious conflicts occur.
The Closer the Better
While we recognize that this may not be possible for every business, we’ve found that having your dev and QA teams in the same building can help improve communication immeasurably. Aside from the personal connection that can be established from face-to-face contact, one of the benefits of having your teams in the same building is a reduced reliance upon difficult and inefficient communication methods like email or chat. It may seem simple, but the ability to talk through challenging or complicated issues can shrink a days-long problem to a matter of minutes.
Schedule Consistent Updates
It doesn’t matter who you are or how good your dev team is—the unexpected is inevitable. That’s why a key responsibility for any development team is to communicate with business/QA teams about the progress of a project. Is work coming along on schedule? Have any unplanned issues arisen?
By documenting these items on a regular basis, you’ll give your QA team the chance to adjust to the reality of the development cycle. The earlier QA understands how code, features, or timelines have changed, the more time they’ll have to think creatively about how their testing plan or methods need to be modified.
And don’t worry—this doesn’t take much! Schedule quick, 5-10 minute meetings between team leads each day, and in the time it takes you to drink your coffee you’ll have drastically improved the ability of your teams to work together.
Thorough, Honest Feedback
Once testing has begun, it’s the QA team’s turn to hold up their end of the bargain. When errors are found, for the sake of reducing confusion and miscommunication, it’s critical to thoroughly document all steps used to test the implementation. While written descriptions and screenshots are useful, it’s easy for key pieces of information or context to get lost in translation. Consider providing screen videos of the test, so that the developer can see exactly what the QA saw (and possibly more).
If step-by-step documentation and video isn’t enough, and the developer is still struggling to reproduce an error, work to establish direct communication instead of email. Schedule a few minutes to screen share and talk through the issue. This will get both sides to a solution faster, and reduce the frustration of exchanging written messages that often take too long to compose and can struggle to capture the complexity of an issue. It may even be beneficial to include a business resource in the discussion; if a feature isn’t working to spec but meets the original need (and might even be a better solution), the BA may be able to help the team avoid unnecessary churn and bug fixes.
Post-Project Reviews
An easy step that’s even easier to overlook is the post-sprint review. Schedule a short meeting with all team members to discuss their experience of the development process. What worked well? What could be improved? Where did gaps or miscommunications occur? Why?
When everyone is pushing hard towards a deadline, it can be hard to make process changes midstream (even beneficial ones). Post-sprint reviews allow you to identify what process changes would help, and prepares the team to implement them next time.
So What?
Without a healthy relationship between your dev and QA teams, the development process is sure to be marked by frustration and inefficiency. Gaps in communication will occur, timelines will get set back, and the overall end product will suffer. Being patient, empathetic, and kind should be emphasized on all sides, but going above and beyond to build a relationship will help ensure a productive and rewarding work environment. Fortunately, as we’ve outlined above, doing so doesn’t have to be a burden. Give these tips a shot, and watch the collaboration between your teams improve for the better.