Have you ever had a strong disagreement with a co-worker? I'm guessing that every single person reading this will answer with a resounding "Yes!" Anyone who's worked in a team knows that there will always be others who won't always agree with your thoughts and opinions about your work or organization. Every person has different experiences and beliefs, and it will happen anywhere you collaborate with others.

It's not a bad thing, however. For the most part, those differences of opinion are healthy parts of any thriving organization, especially when it comes to innovation. Different perspectives on a problem lead to breakthroughs that would have never come to light if everyone had the same mindset. The important thing is how the people involved handle the inevitable conflicts amongst team members in an organization.

Handling potential discord between teams is often a delicate balancing act. Still, it's even more tricky when a spat occurs between groups with somewhat different attitudes towards their tasks despite working towards a common goal. One of the areas where I've seen this flare up the most in my line of work is between software development and quality assurance teams. Despite both groups wanting to build products that work well, many workspaces have dueling development and testing teams.

Take a glance at any software development or quality assurance forum out there. You'll find a few comments or posts of one group bashing the other almost instantly. Comments like "The QA team keeps slowing us down " or "If devs didn't write such crappy code, we wouldn't have to keep opening tickets" demonstrate how these rifts play out in many organizations. I'm not saying one side or the other is always correct. But leave these feelings unchecked, and it can bring down your organization thanks to uncoordinated efforts to make a quality product.

So how can you prevent disagreements between QA and development from creating an ineffective work environment? I've been on both sides of the fence throughout my career—mainly as a developer but plenty of times as a tester—and have my fair share of clashes with fellow teammates. I've seen what causes these problems to fester and what works well to prevent them from boiling over. If you're currently in the middle of this kind of feud, here are a few things your organization can do.

Set expectations clearly on both sides

Most altercations—not just at work but also in life—come from misunderstandings. At work, we usually deal with clear and direct instructions on what we need to do, defined by our job titles and roles in the organization. You'll know what you need to do your best work. However, we also carry assumptions that make us believe that everyone else also knows what you need, and that's where the problems begin.

For testers, a lot of resentment towards the software development team comes from a perceived lack of testing when new functionality lands on their plate. A common complaint I hear from testers is how little testing a developer does with the code they just wrote, either in the form of no automated unit tests or regressions popping up in the test suite. It adds a lot more work to the tester's already-loaded plate.

On the development side, a source of frustration comes in the form of bug reports that seem unclear or lack information that would help a developer isolate and fix the issue. For instance, they might need a screenshot of the defect, an error message that popped up when the test build crashed, or detailed steps to reproduce. Instead, they receive a ticket with just a few sentences on how they got the error.

In both cases, the problem usually comes from something that was not said clearly from the start. Did the development team know they're responsible for writing unit tests or checking regressions before passing their work to QA? Did the testing team know what information helps the development team fix bugs in their code? For most developers and testers, the answers to these questions seem obvious, but that doesn't mean it's clear to everyone else.

No matter how evident something seems, it still needs to get communicated clearly. That's why it's essential to set expectations for each team. For instance, who's responsible for writing the automated tests for new functionality? What information do bug reports need before submitting to development? Understanding what each team and team member needs eliminates assumptions and will significantly reduce misunderstandings that create massive conflict.

Work together, not separately

It's unfortunate that most organizations completely separate their software development and quality assurance teams—both physically and psychologically. Even when most organizations had their employees working in packed offices, it was rare to see the developers in the same room with the company's testers. With the rise of remote work, the mental separation grows even stronger. A clear example of this shows up on almost everyone's Slack accounts—there's a good chance your work Slack has separate channels for development and testing, with few members subscribing to both.

As mentioned earlier in this article, both development and QA have a common goal. So why do we have to keep these physical or virtual barriers between us? The most dysfunctional software organizations I've seen have very clear distinctions between development and testing, and it always fosters an "Us versus Them" mentality that serves no one.

Developers and testers, ask yourself an honest question: when was the last time you worked or even talked with someone outside of your role that didn't involve dealing with bug reports? If it's been far too long—or even never—don't worry. Most of us have been there before for different reasons.

The good thing is that it's never too late to begin working together to generate the best possible work for the organization. One strategy I often encourage others to do is regularly pair between different disciplines.  It helps both sides learn what each other needs and is possibly the most effective way to eliminate those assumptions and misunderstandings mentioned earlier. Another good way to work together is to get everyone involved in planning from the start. Most teams have separate discussions when beginning a new project, which expands the gap between groups.

No matter which route you take to work with different teams, the key here is to establish a fundamental working relationship with the developers and testers from both sides, not just those who share your job title. Trust between teammates is crucial to success, and the only way to gain that trust is to build those connections while at work. You don't have to be drinking buddies (although it helps a ton), but try to eradicate any separation that exists between each side.

Get other departments involved in the process

Like developers and testers need to work together, most software development organizations have many groups working towards their business objectives. Many modern workplaces have product and project managers, business development, marketing and sales departments, and more. Even if most of these stakeholders don't do the tangible work that lands in customers' hands, their roles are equally critical to the project's success.

Sadly, most technical departments like development and testing disregard these other roles for their work. Since other organizational functions like BizDev and project managers usually don't produce tangible results, it's not uncommon for a developer or tester to fail to realize their importance in the overall product. But technical departments shouldn't underestimate their planning and coordination before the work lands on the dev and test side.

I have a personal story to show how vital other departments are to development and testing. At an organization I once worked in, we were a small team of developers and testers working on a web application. The company didn't have any formal project management, so the team leads were left to choose priorities for their respective groups. Both the tech lead and the QA lead had different ideas on what needed focus, and that's where everything began to crumble.

The tech lead focused on cranking out as many new features as quickly as possible without addressing any technical debt that had accumulated throughout the project's lifetime. The QA lead, tired of constant bugs, slow regression testing, and getting blamed for missed deadlines, focused on building test automation. It eventually set them on a collision course to failure—lots of in-fighting, plenty of turnover, and a buggy product that was dead on arrival.

Although this is probably a case where nothing would have solved the underlying issues between team leads, I believe that better coordination and management earlier in the process would have corrected the problems before the whole train veered off the tracks. If setting expectations and working together isn't yielding results, take a step back further and see if there's proper management to support development and testing. Without that support, your efforts will eventually reach a point where it'll become difficult to proceed.

Use retrospectives as opportunities to improve

With the increase of agile methodologies, the retrospective meeting has become a staple in most software development organizations, and with good reason. In the daily grind and trying to wrap up sprints, it's easy to lose track of how we're doing, how we're getting along with others, and why it matters. Taking a moment every week or two for reflection pays off big time down the road.

In theory, retrospectives should be an energizing experience, leaving you and your teammates feeling great about whatever's coming next. That's not always the case, especially in dysfunctional teams where a retrospective often falls into finger-pointing and throwing blame around for the things that didn't go well. But the least effective retrospectives are when there's silence since it defeats the purpose of taking this time to talk about areas of improvement.

Another frequent mistake made in organizations is when teams do siloed retrospectives. For example, the development team holds their retrospective separately from the QA team. Some departments do this because team members are most comfortable with their peers in the same group. However, it also defeats the purpose of a retrospective because developers and testers don't work in a vacuum. The success of their work relies on what they do as a whole.

There are plenty of books, blog posts, and YouTube videos explaining how to run a retrospective successfully, so I won't dive into those details here. However, in the context of improving how testers and developers work together, your organization needs to take the time and space to bring both teams together frequently. There might be some pushback to hold these meetings separately for different reasons. Still, the only way to prevent misunderstandings and poor communication is to have everyone in the same place and give them the space to talk.

This meeting time should provide a comfortable space to bring up any issues found during recent weeks. Some or all of the suggestions discussed in this article—setting expectations, working more closely together, and involving other departments—will likely surface in the discussion. If bringing up these issues is uncomfortable for you, it's a sign that something needs improvement. Don't be shy to voice your thoughts, no matter what. These meetings will flow smoother after the first few retrospectives with noticeable improvements and increased positivity as time rolls on.

Summary

No workplace is perfect, and you're bound to get into the occasional dispute with your fellow team members. Still, these arguments seem to pop up more frequently between developers and testers, whether it's miscommunication or disagreements with the work getting done. If you're in an engineering or QA team and can't seem to get along with the "other side", you and your organization can begin taking steps to address the issue before it deepens the divide.

Most sources of frustration come from not making clear what's expected from development and testing, so setting those expectations early will keep the resentment at bay. Finding ways to have testers and developers work closer together also helps reduce any potential disagreements in the long run. When other departments outside of dev and QA are involved, like project managers, loop them in to have a smoother workflow from start to finish. Finally, schedule recurring retrospective meetings to ensure all grievances get aired out and begin the path towards improvement.

Admittedly, getting developers and testers on the same page isn't as straightforward as this article makes it sound. Depending on your organization and team members, it might take a lot of time and patience to ease any tensions. However, it's worth the effort to make an enjoyable workplace where everyone does their best work. Nothing makes a better product than when the people working on it, especially development and QA, are walking on the same path without creating any obstacles between them.

How else do you handle problems between developers and testers, whether it's as a manager or a team member on either side? Help others out by sharing your tips in the comments section below!