There are many essential components to what makes product teams successful and efficient.
As a Software Engineer, having worked with different user-focused product teams over the years, I began to reflect on what truly makes collaborative processes smoother in the lifecycle of a project.
Somewhere along the journey from ideation to shipping to production, Developers and QA Engineers interact to accomplish big feats like fixing bugs discovered by users or bringing new, highly anticipated features to fruition.
Not every company officially utilizes QA testing as part of its development process. When a Developer has made changes to the codebase that they believe meets the requirements for some ticketed work, they’ll pass the work off to a QA Engineer for testing and approval before it can officially get out to real users.
This is a typical workflow at companies where QA testing is a step in the development lifecycle.
Teams leverage the meticulous skill sets of the QA team to ensure things that already exist on the platform aren’t negatively impacted and that the pending changes are working as expected.
Therefore, it’s reasonable to state that this makes the QA and Developer relationship a very crucial aspect of the success of a product, individual contributors, and the teams they work on. QA Engineers and Developers must build and maintain trust throughout the development cycle and project lifespan.
After speaking with a few QA Engineering professionals, researching, and considering what I’ve learned in my career so far, I’ve summarized some key elements of building and maintaining trust between QA Engineers and Developers that I believe can be implemented immediately within your teams.
Take these points as an opportunity to:
- reflect on the ways you’ve been investing in QA Engineer-Developer relationships
- consider improving support to make these individuals successful and efficient at their respective jobs
- consider formalizing processes that will optimize the development cycle steps that directly impact QA Engineers and Developers to reduce operational costs and improve teamwork experiences
Standardize How You Communicate Intentions of Upcoming Developer Work
Initially, it’s worth meeting with the team to discuss opinions about the existing way QA Engineers and Developers are expected to work together.
This is also a great way to get feedback on the needs of both QA Engineers and Developers moving forward. Any action points gathered from this type of meeting could be revisited in the future to modify as needed.
Now, let’s imagine a typical Agile development scenario where a certain amount of themed work is allocated to a two-week time frame known as a “sprint.” Designers might have wireframes or prototypes of what is envisioned for a feature to look like and function. In another case, team leads have come up with an idea of what a bug fix should look like.
Firstly, it’s important to be intentional about communicating the purpose of ticketed work that QA Engineers will have to test. This could be via informing them in your communication tool like Slack. This could also be accomplished through a quick call where Developers can share their screens and demo what they intend to solve.
The point of this is to keep QA Engineers in the loop and do so in predictable ways that both sides are aware of. For more simple changes, maybe a few messages are sufficient. A more detailed walkthrough would be more suitable for more complex changes, with an opportunity for Q&A, so ambiguities are cleared up.
Provide the context around what Developers have been spending their time on. Highlight the problem and explain the solution in a way that is simple. It is less about the technical details of the implementation and more about clear differences in the step-by-step experience within the product.
However, keep in mind that some QA Engineers might take more specific technical information and respond with questions that will ultimately affect their testing experience, such as a solution’s potential impact on application performance.
“It’s important to focus on details in these cases but to also see the horizons. It helps to build a test strategy.”
— Maria, QA Engineer @ O’Reilly Media, Inc.
Help QA Engineers optimize their own time management by being mindful of how soon they should know about work that will need to be tested soon. This is empathy and consideration for efficiency in their job, and efficiency of the team as a whole.
Standardize Documentation of Details That QA Engineers Can Easily Reference For Testing
When it comes time to move into the testing phase, I can assure you no one wants to play a guessing game with how to test a feature or bug fix without any context. Searching for those answers across different communication tools and project/product management platforms that your teams utilize is an exhausting and inefficient use of time.
To mitigate the arduous process of hunting for sufficient details of the work coming from Developers, here are some tips:
- Leave notes underneath ticketed work or, generally, in some visible place the QA engineer can quickly go back to reference.
- The notes should include steps when necessary. It should also make it clear what Developers expect the results of the tests to look and/or function like. If possible, provide example data for expected input and output of basic feature testing. This can give the QA team a healthy starting point to build upon.
- Try not to over-direct them through testing steps. This could promote tunnel vision stemming from the Developers’ bias. The whole point of thorough testing is to approach the problem that was solved with fresh eyes. Always remember to maintain the integrity and value of that perspective.
From there, help QA Engineers further understand the purpose of what you’re solving by explaining what is out of scope for your work! It helps to “evaluate the state of the project,” according to O’Reilly Media QA Engineer Maria Margolina, as knowing the bigger picture of the overall progress Developers have made is just as important as the details of the ticket right in front of them.
Use QA Feedback to Optimize Planning & Development Processes
Now that the testing process has occurred and QA engineers have returned with some feedback on the changes, there are a couple of directions things could go from this point onward:
- There could be minimal to no concerns raised with the technical changes made in the codebase. Thus, the changes are eventually approved to be deployed. Testing in production can occur whichever way you see fit and have established within your team.
- A few questions are raised about the recent changes that are worth addressing. Something outside of the focus of the work has broken, and the work itself isn’t fully solving the problem correctly. Now, it’s time to decide how and when this will be resolved.
Let’s say the latter pathway is the scenario we find ourselves in. Take mental or physical notes of the type of comments that were provided. This is an excellent opportunity to analyze feedback.
Here are a few questions worth asking yourself:
- Do these comments and questions seem similar to other ones that have been made in the past?
- Is this feedback curious enough to have larger discussions about a feature’s initial purpose/value? These discussions could happen team-wide or just among team leaders.
- Is this feedback speaking to some larger gaps in the planning and development phases that are often forgotten or ignored? For example, are we not always considering how different categories of users are supposed to experience the platform? There is a chance that some bases are not consistently covered that impact user experience (whether internally or externally) on your platform.
- Do we have an opportunity to catch these types of raised issues before Developers hit the ground running with code? How can this information be made available for relevant team members?
Leverage QA feedback to create (or contribute to) a system that improves the quality of the Developer's work, which can help your team cover more bases when working on new projects and tasks. These systems could take the form of checklists wrapped into code reviews.
Work can feel personal sometimes. It's understandable if occasionally getting work returned to Developers to fix can feel like an attack on their ability to code well. While it might not be feasible for everyone to adopt, I try not to take QA feedback personally. They're there to help you, aid the team, and positively impact users who will interact with your features.
They are the last stop that holds the team's reputation in their hands. The fewer bugs, the better, while keeping in mind there can be a balance of quality work and room for iterative development!
Questions to Raise for Improving the QA Engineer-to-Developer Relationship Dynamic
- When is the right time for QA to test something that could be messy? Is it confusing? Is it too much context switching?
- When possible, could bugs found in the code be fixed within the same sprint? Discussions around this can help create realistic expectations of overall progress within the project and reiterate the level of priorities for existing work.
Conclusion & Takeaways
There are strategies and perspectives that Developers and other team members can foster to improve communication, empathy, and efficiency through collaboration. This builds reciprocal respect and sets the tone for quality work to get done.
When you invest in systems and processes within your team, you make it easier for Developers and QA Engineers to trust the quality of each other's work, the scope of each other's roles, and the value of necessary discussions that happen along with the project phases. Thus, it becomes easy to answer the question of how should QA engineer communicate with a Developer and vice versa.
When you invest in an empathetic dynamic between these two types of roles, you're ultimately improving productivity, collaboration, communication, time management, code quality, iterative development, and the overall team culture.
Ultimately, you hold team members accountable and create more comfort and ease in their work experiences.
The more systems and processes are documented, standardized, and optimized for everyone, the less initial mental effort it will take to remove blockers so awesome work can get done.
