Software development is a complex and dynamic process, and the key to delivering high-quality applications lies in the hands of a crucial team player: the Quality Assurance Engineer. QA engineers are responsible for ensuring that applications are reliable, efficient, and user-friendly, and they play a critical role in saving time and resources for companies. To put it simply, QA engineers are amazing.
However, as much as QA engineers are valued for their contributions, one aspect can sometimes lead to challenges: communication with developers. Yet I firmly believe that this (spoiler alert) can be easy. With the right approach and mindset, communication between QA engineers and developers can be smooth and productive. And that is something I learnt at Mews. Of course, this is not a universal source of truth. It is simply my experience which helps me a lot on a daily basis, and I hope it can be helpful to you as well.
To underscore the importance of communication is a quote from award-winning software delivery consultant Gojko Adzik, who stated, "I am getting more convinced every day that communication is, in fact, what makes or breaks software projects." And I cannot agree more. Communication plays a vital role in ensuring a project’s success. How often have you encountered a situation where a lack of clarity led to misunderstandings and disagreements? Or felt solely responsible for a bug that slipped through production due to a lack of clear communication?
When searching for tricks and tips on QA communication with developers, I have often stumbled upon the advice not to rely on what a developer says. Or that it is critical to find proof to back up statements such as "everything will be okay" or "changing one string in the code won’t cause any problems." My approach is exactly the opposite, and that is:
Solution 1: Build mutual trust
This is one of the essential elements on which I base my communication with developers. Building mutual trust ensures effective collaboration. By fostering a team spirit and believing that I work with super dope professionals who can nail anything, by recognizing the expertise of the developers I work with, I place trust in their judgment. So if a developer tells me those code changes won’t break anything, I trust it. And if issues arise, I may ask questions to understand what went wrong but only to know how to prevent similar blockers in the future. And the next time in a similar situation, I do not doubt the developer’s competence because development should not be driven by distrust – but rather by a desire to improve our processes. It is important to raise concerns in a collaborative and supportive manner.
Trust is a vital component in any relationship, including that between team members. Being distrustful creates an unfavorable atmosphere causing motivation to decrease. Quoting the movie "Moulin Rouge", "Without trust, there is no love!". There is no love for the app you’re building if your peers, teammates, or colleagues don’t trust in the work you’re doing. Why would you care, then? Trust is fundamental to ensuring everyone is invested in the work they are doing.
While preparing for the ISTQB Foundation Level exam, I learned that there is a whole chapter dedicated to the psychology of testing and how QAs should communicate with developers. As someone who wasn’t a QA at the time, I found this chapter somewhat intimidating.
The syllabus highlights the difference between a developer’s and a QA’s mindset. Developers are focused on creating solutions without overthinking what might be wrong with these solutions, while QAs are more concerned with identifying potential issues. And this difference in mindsets is aggravated by a confirmation bias that developers may have. This bias refers to the tendency to only accept information that supports one’s own ideas. So, when a developer puts effort into coding something but a QA reports a bug, the developer may see the QA as just a bearer of bad news and defend the code. This situation creates the perfect breeding ground for an argument.
My suggestion in this case is:
Solution 2: Share the mindset
What I believe is wrong with the standardized distinction of mindsets is that QA engineers may form biases towards developers, assuming they only build things and can’t have an idea of what could go wrong. It is a bad assumption that immediately puts you in opposition to the developer. Instead, I prefer sharing the mindset. For example, when we have new developers on the team, I like having a call with them (costs of remote work) to show the application from my QA perspective. They can grasp the codebase quickly, watch videos created for users of the app that demonstrate the happy paths or speak with other developers to learn about known pitfalls to avoid. But I can convey the QA side of the system, highlighting what I would usually test and how I connect the dots for new functionalities or updates to existing ones. And yes, I’m sharing my knowledge, but at the same time, I believe I’m also sharing the mindset. From my side, I also try to dive into tech terminology as much as possible, solve problems with the team, and understand the system’s limitations. By doing this, I’m trying to avoid creating biases in my head.
Are you a QA? Are you an engineer?
And would you like to work with Anastasiia? Click below! 👇The concept of distinguishing mindsets can be valuable, for instance, when figuring out what career path to follow in tech. But when it comes to coworking, it hasn’t really helped me.
Another true story from my life is relevant to the biases mentioned above. At certain periods, I felt like I had become a real pro in my field due to heightened domain knowledge from constant testing. I basically felt like a real smarty-pants. This mainly happened when I was overwhelmed with work and found myself in discussions where I felt the urge to impose my solution without fully considering other perspectives. But in what position did that put me? With that kind of thinking, I took on all the responsibility because I demonstrated that I know best.
During my first year at Mews, it happened multiple times that I mistakenly identified a perceived issue as a bug. This led me to hastily create bug reports and reach out to developers, only to learn that the functionality worked as intended and errors were caused by my own missteps in test cases. So, I generated conversations and distracted my colleagues with something I could have spent more time investigating myself.
For these cases, I suggest:
Solution 3: Doubt yourself
As Quality Assurance professionals, our role involves questioning and scrutinizing development ideas on a regular basis. However, questioning oneself may seem counterintuitive or even unprofessional as we are supposed to exude confidence in our work, which centres around ensuring quality. Yet, I have found that embracing self-doubt has actually been highly beneficial. It saves me time and reduces the workload of developers, as I make a habit of spending just a few extra minutes verifying the validity of a bug before reporting it.
Another example of when doubting oneself can be beneficial is the classic quote, "It’s not a bug, it’s a feature."
As a QA engineer, admitting that I might be wrong and that what I see as a bug could actually be a feature can greatly improve the outcome. The ultimate goal is to deliver functionality that is usable and serves a purpose. I think that if a bug turned into a feature request is not prioritized or denied, it falls on the QA to explain its importance. It’s also good practice to consider that what one perceives as a critical issue might not be important at all.
Conclusion
To bridge the gap, I suggest focusing on common ground. Firstly, build mutual trust. Establishing trust starts with overcoming personal biases and working together towards collective goals. Secondly, share the mindset. Communication is essential to sharing your thoughts and understanding with the other party. And finally, doubt yourself. Don’t be afraid to question your own ideas and assumptions, as it can lead to better communication and fewer unnecessary conversations.
This post is based on a talk I delivered at a QA meetup back in December, which you can watch here. The conclusion remains: a change of perspective can go a long way. 😊
