The strained dynamic between QA engineers and developers is pretty well-known throughout the software industry. This stems from the vastly differing natures of their jobs. Let us have a look below.
Developers:
- Concerned with coding and often tight deadlines
- Create codes that perform a particular purpose
- Technicality of their work may inhibit them from taking into account the user’s perspective
QA Engineers:
- Concerned with quality
- Responsible for cultivating a consumer viewpoint
- Ensuring quality for the end-user
As you can see, their roles are starkly different from each other.
The Verdict?
Trouble!
How to resolve it?
Let us tell you below.
Step 1: Channel your energies towards the end-product
Whether you are working in the capacity of a QA engineer or developer, your ultimate aim is to increase quality of the end product. Think of this as your common goal, one that both of you are working towards achieving. And that goal, is a high-end user experience. So, instead of emphasizing on the divisions in your work—a practice that directly or indirectly sows the seeds of conflict—your focus should be concentrated on your mutual agenda, so as not to lose sight of the end goal. Do thorough research on your users and their needs and wants, so that you have a sound grasp of what they desire and expect out of the product. Gather the relevant resources. Implement your findings in your work. Whether you are a QA engineer or developer, your focus should be on the user—in terms of how they use the application, and how your product creates value for them.
Ok, I get it…I need to have a common end-goal with my dev-counterparts. But how will this ease the process of working together?
Step 2: Enjoy your journey together
The answer to the above question is actually more straightforward than you would’ve expected. Once both teams have fully grasped the idea that they are working towards a common goal, the next step is to enjoy the journey together. This includes: supporting each other, giving constructive feedback, having review sessions—so on and so forth. Both teams should feel that this journey is for them to work together and make the most out of it. Cultivating this mindset will make a tremendous difference to how you approach things.
How can you tell me to enjoy the journey when the ever-present bugs foster so much frustration and angst amongst all of us?
Step 3: “There’s always one more bug to fix!”
Let go of the fantasy that your product will be completely bug-free. This may hurt to hear, but there is no way to guarantee a total absence of defects in your product, regardless of how much it has been tested.
Being a QA tester does not mean that you are required to fix every single flaw you come across. In fact, it’s not even possible to do that. You have to prioritize your tasks, wisely.
Using this risk-based approach, you have to try to minimize the severity of bugs together. Aim to employ a mechanism whereby bugs can easily be filtered out if they arise, and the test coverage should be enough to make it through.
I want to know more about prioritization. What will happen if I don’t do it?
Step 4: Why should I prioritize?
Prioritize for quick wins. If you, as a QA engineer or developer, don’t prioritize, you’ll keep going back and forth on different angles, and will never be able to focus and eliminate problems as you will keep fighting with each other. On the other hand, if you have to achieve a target as a team member, the beneficial thing would be to prioritize items so you can focus on that particular task. Consolidation is key!
Cool. You make prioritization sound so easy! I’d like to know more about how to do it, though.
4.1. How do I prioritize?
Identify which issues are critical and need to be dealt with urgently, and which can be avoided or are not necessarily important enough to spend time fixing. Not prioritizing efficiently will lead to everyone wasting time and effort on addressing problems that are not as crucial, which will consequently result in the important tasks being neglected.
Thus, don’t go in with the idea that you have to resolve every single bug or defect you encounter. Instead, categorize the bugs according to their importance and work on addressing them in a methodological manner.
Right, right. What if I feel that my dev-counterpart isn’t prioritizing correctly? Or for that matter, how do I tell them that I disagree with any other of their approaches or practices (which, just by the way, happens all the time…)
Step 5: Give critical feedback with care
When you’re not careful about giving feedback in a constructive manner, things are bound to backfire. This is a major source of conflict between QA and developers. Reckless claims and accusatory tones trigger negative connotations and initiates a friction between the two roles. At times, the situation can get so bitter that there is no rollback. However, if both of you focus on the end product, enjoy your journey together, remain respectful, and prioritize so as to focus on things, you need to be very careful on how you give feedback. Your feedback should be sincere. Your choice of words matters a lot.
Now, we will observe how, for instance, a QA’s choice of words can make a difference to how the developer receives it. Consider the two scenarios below:
Scenario 1: (QA to developer) “This is not working! The code keeps crashing! What have you been doing this entire time?”
Scenario 2: (QA to developer) “I’ve been trying to figure this out but somehow this step is not giving the desired results. Is this something we have in the scope document? Did we have the right test data available with us?”
In which situation will the developer be more receptive to the QA’s concerns? Of course, scenario 2. When the developer sees that the other person is genuinely trying to figure things out rather than lashing out in a derogatory or condescending manner, he or she will not take it negatively. This will foster healthy criticism and develop the practice of giving and receiving constructive feedback—which will work in the favor of both teams.
I have finally mustered the courage to ask my least favorite question: what if something is my fault (which it OBVIOUSLY wouldn’t be, but hey, it doesn’t hurt to ask, right?)
Step 6: Take ownership of your project
As discussed earlier, the end product is the ultimate goal. Hence, the outcome of the product depends not on one individual or team, but on all the teams—regardless of whether they belong to QA or developers. As a result, it is important for everyone to take accountability of the end-product, rather than picking faults in the other party’s work. Everyone is assigned a different role according to which they work, and they consequently contribute towards the overall testing process. Developers ensure that appropriate unit tests are written, technical issues are fixed, and the coding is done accurately. The entire system is tested by QA, keeping in mind the user experience. Thus, you are working alongside the other, not against. Adopt this mindset and you yourself will notice a change in your relationship with the other party.
This is where your leadership skills are also tested. If both of you are working together on a common goal, on the same journey, are aware of how to give and receive critical feedback, then you should also know how to take ownership when something is going wrong. Doing so cultivates a solid relationship between both the parties involved, as there is a sense of togetherness. You should own your mistakes openheartedly because your drive is towards a mutual objective, not a personal gain.
A small issue: I want my colleagues to know me better, only then will I feel comfortable speaking up about my mistakes. How do I enhance my presence?
Step 7: Communicate and Collaborate
Make your presence known by voicing your opinions, thoughts, and ideas. This will enhance teamwork and confidence. QA engineers and developers should be open to sharing their ideas with one another, and paying close attention to how the other approaches things. Don’t be hesitant to speak out or interact with teams who are working on tasks of different natures. This way, QA engineers can get to know developers better, and vice versa. This will consequently lead to both parties developing better understanding with each other, thus diminishing seeds of conflict.
I am certain that all these tips will help me transform my relationship with my dev-counterparts, tremendously. However, it is a lot of information to take in. Could you sum it up for me, please?
Takeaways:
- Conflict between QA and developers arises from differences in the nature of their respective work;
- Invest your time, energy, and resources into the end-product;
- Enjoy your journey together;
- No point in trying to resolve all bugs;
- Prioritize for quick wins;
- Give critical feedback with care and sincerity;
- Take ownership of your project;
- Speak up and share your ideas.
