[Originally published on TestCraft ]
The relationship between developers and QA engineers is often a work-in-progress. There are some long-lasting stereotypes on both sides that can contribute to tensions – “Developers just throw the work over a wall” or “QA engineers block the work from getting deployed”. At its core, this way of thinking is a trust issue – neither one of them is trusting that the other has good intentions in how they work and collaborate.
Creating a foundation of trust, collaboration, and communication is vital to team morale and a positive working environment. It also enhances the team’s ability to produce work that you can have confidence in because it was a joint effort – collaboration – to ensure its quality.
In my experience as a QA engineer, I’ve worked with the developers on my team to overcome these tensions and create a positive professional relationship. It’s not always easy, and it can take time to build new habits, but it’s absolutely worth the effort! Here are some of the solutions that we found for creating trust and collaboration – I think you’ll find that they can work for you, too!
Build trust through better communication
Improved communication goes a long way towards building a foundation of trust between developers and QA engineers, and pull requests (PR) are a great place to start.
When developers are creating a PR, we’ve generally found that it’s useful to include sections for a link to the ticket, a summary of the work, and test steps. Once you decide what’s useful to include in your workflow, make a template for it! That way the sections you need are automatically laid out, and the developer just has to fill in the relevant information.
The link for the ticket is just a nice bit for your QA engineer, so the ticket info is easily at hand for them. Summarizing the work you did gives the QA engineer some insight into the “how” and “why” around the feature work, and adds context when reviewing the actual code. Most acceptance testing or feature testing involves exploratory testing as well, but including specific test steps also help QA engineers focus on the most relevant changes. Test steps also have a side benefit for developers, by giving them another chance to review their work against acceptance criteria as they’re writing the steps.
The effort that you put into creating a good PR is a way of working with your QA engineers, even though it’s happening asynchronously. It shows that you care enough about the work they’re doing to make sure they have what they need to do it well.
QA engineers need to make it a habit to give positive feedback on developers’ PRs. If you only comment when there’s a problem, all of your comments will start to seem problematic. Take the time to show that you’re giving meaningful attention to the developer’s work. For instance, I’ll point out a good UX solution, or show appreciation by noting where they reduced tech debt. Even a simple “Looks good – verified x, y, and z” counts as positive feedback, because it shows that you’re noticing what they’ve done. People often have a negativity bias, so being mindful of the type of feedback you give – or are perceived to give – is especially important.
When developers and QA engineers create a pattern of positive communication, it sets a foundation for how they interact with each other and enhances your working relationships. More frequent and more mindful communication also creates an environment where it’s safe to raise concerns and give feedback, so communication can flow freely.
Understand your QA team
QA engineers often end up with a very hybrid role, which means they get a variety of experiences with different teams or companies. Get to know your QA engineer’s background and experience, as well as what they’re interested in learning.
For instance, some people excel at detailed exploratory testing, while others may be skilled at setting up and troubleshooting continuous delivery pipelines. Do they come from a programming background? Do they have experience with performance testing or security? Do they enjoy process creation and focusing on improving developer experience? The answer is probably “Yes, and” since a common trait among QA engineers is constant curiosity.
Along the same lines, most developers I know have a specialty or preferred area of the stack that they focus on – front-end gurus who can work magic with SASS and styling; a back-end focus with a knack for building intuitive APIs; security-minded devs who have a knack for OWASP considerations.
Knowing more about each other’s experience, areas of strength and goals for learning leads to better relationships and improved collaboration. Understanding my team’s background meant that I knew who to ask when I had a sticky front-end problem, or who to pair with when I wanted to learn more about security testing. It also gave us more context into who our colleagues were as people, which created a more empathetic mindset when we interacted with each other.
Collaborate in the problem space
When trust and communication are lacking, QA engineers are often silo’ed within the development workflow. Break out of this pattern by including your QA engineers early in the process. Bring them into project discoveries, where they can make recommendations for test plans and architecting for easier testing down the line. If you’re discussing a bug or blocker, loop them into the chat – not only does it increase their context and overall awareness, but also helps QA engineers contribute to finding causes and solutions.
QA engineers can help make this shift for themselves as well. For example, when I’m working on this “shift left” mindset, I look at my team’s calendars to see what meetings I should participate in. If my team has a central source for discovery documentation, I’ll create a test plan or testing templates and add them in. I also make sure to talk about my work with my team in standup and retro, so that my work isn’t silent and therefore overlooked. If I’m adding tests to check for a bug that keeps cropping up, I mention it to the developer so they can run the tests when they’re working on it.
It takes time for people to change their habits, so be patient and keep the conversation going – remind them how being included benefits you and helps you do your job better. If you can explain it that way, instead of just wanting them to do the “extra work” of looping you in earlier, they’ll be more motivated to do it. Of course, they want their QA engineer to be supported, and if they can help you carry out your job more effectively, they will.
Stop. Collaborate. Listen.
I generally wouldn’t recommend taking your life advice from Robert Van Winkle; but in this case, he was onto something.
When you have improved working relationships, you have happier people who feel safe in their work and team environments. That means everyone can focus on the actual projects, instead of being blocked by poor communication and a lack of trust.
Mindful communication, consistent collaboration, and empathy for the people you work with create a strong foundation for a high-performing team. Working together, you’ll be able to increase the quality of work you produce and have a smoother development workflow from start to finish.
Top comments (0)