The relationships and peculiar mismatches between the testers and the developers have long been the butt of a joke. But to solve both employers' and customers' tasks, holders of these two job titles need to be able to patch up their differences within a single ecosystem.

Tester: The release must be postponed!
Developer: Why? What makes you think so?
Tester (looking concerned): All the tests are going without a hitch. I can't just figure out why…

If the developers and the testers held jobs at emergency services, it would be something to the effect of:
'Hello! Please come! A yellow high-rise is on fire!’
'Um, you know, I can see a similar yellow high-rise nearby. It's not on fire.’

As I was getting to know the team, the first thing I heard the developer say was: 'I really hope we won't be constantly all over each other with those bugs.’ This epitomises the communication issues between the two structures. So let's get to the bottom of the conflict.

A conflict is an instance of social interaction between the participants that hold mutually exclusive or incompatible views. Every person has their individuality with their own views and values that inevitably lead to a situation where every problem is approached subjectively.
The key psychological rationale behind interaction-related conflicts has to do with the conflict potential of the interaction environment, different goals, ongoing psychological discrepancies, psychological manipulation and pressure by the participants, the conscious twisting of the information, the conflict of interests, and other factors. When the two divisions, one of which is tasked with programming and the other with testing, are in close interaction, potential feuds and misunderstanding are so predictable, it is rarely even discussed.
A. Antsupov, A. Shipilov. Conflict Resolution. Moscow, 2009.

Developer

A developer creates and develops the product. Their way of thinking may indeed incorporate some features of the way the tester thinks. However, accomplished programmers are keener on implementing creative solutions, rather than considering possible flaws to them.

No one's work is immune from mistakes. But only a few do have qualities that enable them to identify and fix these mistakes. In most cases, when you point to someone's mistakes, they view it as a personal grudge. So the psychological effect is quite straightforward here: they who report a bug come across, as it were, as being more competent. They act as witnesses to someone else's flawed development and, with it, a failure. It may be a small failure, but failure nonetheless.

Artyom Alekseyev, lead developer:

Let me share a brief description of the experience I had working with QA engineers, testers, that is.
I heard people say multiple times that the tester and the developer are opposing each other, though I had a hard time figuring out the things over which they could be at odds.
And here you need to bear in mind the goal: the implementation of a certain feature.
The development process, as such, involves many aspects, from specifications and setting the task to putting the product into operation. Normally, the developer is interested in the end product meeting the initial requirements.
When implementing any features, it is crucial not just to match these requirements in code but also stick to the architectural integrity and write high-quality and intelligible code. This process is often accompanied by overlooking certain details. And if this has to do with the quality of the code, it is down to the developer in charge and their colleagues tasked with reviewing the code. But if the oversight has to do with business logic and the features that are being implemented, it goes beyond the developer and already concerns the users of the solution in question.
Once the features are implemented, it's quality that takes the driver's seat. And it's the tester that helps the developer achieve the acceptable result. I'd rather even liken it to one participant handing over the baton to the other while developing.
Furthermore, the tester essentially has the developer's back as they consider the features from a different perspective, as a user, and identify the minute details that the developer missed or would have taken longer to pick up on. This makes for a higher-quality end solution, which contributes, among other things, to better developer's cred.
It would perhaps be easier to view the situation using the personal experience in development. I've always considered fastidious and picky testers my best allies when it comes to the improvement of the end product.

Tester

The tester targets disruption, that is, a biased and purposeful detection of someone else's errors, bringing the system to failure through dynamic testing. Could you recall a time you were glad at a person rubbing the list of your mistakes in your face after it had taken you an eternity to complete the work? That's hard to imagine even if you realize that it's part of the work algorithm and that's the way it's supposed to be. Meeting a professional tester carries a hidden agenda to the tune of "you're not a pro.” I think you wouldn't disagree that the psychological aspect of this contact can naturally lead to passive-aggressive behaviors from the product developer and prompt a rift.

Worse still, bias can psychologically further compound the acceptance of the bug report points or comments. Armed with the right way of thinking, the developer can test their own code, but the notorious bias prevents them from doing it objectively. Otherwise, there wouldn't have been a job role of a tester.

Irina, tester:

There are developers who consider the testers less competent and, therefore, don't want to listen to them. There's some definite prejudice about it.

Arseny, tester:

I had some run-ins with developers. It would take them forever to reply to me regarding the tasks, and they would refuse to consider the bugs I'd identified; they'd say it had worked and that those were some petty features.
Some were even nothing short of being hoodlums that were hard to interact with. Sometimes, they refused to help me. I would have an urgent task to address, and they'd go: 'No time. We'll deal with it later.’ Mind you, if the release falls behind schedule, his seniors will turn on him.

The root of the conflict

All things considered, we have identified the root of the conflict: different goals. Whenever people have different goals, any effort to team them up is futile: they will be following their own paths, essentially leading them in different directions.

Therefore, one of the key questions to be addressed professionally is the motivation to understand that both programming and testing are different means towards the common goal both of you are tackling. And this is the release.

To avoid clashes of the two structures involved in the same project, we at Innotech stick to the following principles:

Minimise conflict situations; testing results should be presented as neutrally as possible, and they should be targeted at facts, and not at excoriating the person behind it.
The goals and tasks of the assignment should be clear. Take the trouble to make sure you are on the same page by asking yourself if your counterpart has got it right.
Both sides should bear in mind their common goal: a system working to the highest quality standard.
Work process mechanisms should be coordinated from both sides, factoring in the opinion of both the developer and the tester.
Be empathetic and consider your colleague's sensibilities.
Don't add to the strain and avoid toxic comments or vagueness.
Should you be teaming up for a long time, you’re your colleague about their interests, experience and other aspects of their life, trying to find common ground.

Instead of a conclusion

By following these simple tips, the testers and the developers may not end up being best pals but will be eager to help each other, thus benefitting everyone.

What causes testers and developers to feud and how to avoid it