just as Jakob Lind said in addition to that -IMHO- these clashes can be easily avoided and solved out by putting morality and ownership in work, as If the developer put his real effort and tried to cover every aspect in his current feature, it will lower the number of bugs, and it will add a sense of trust between them, and it will favour the quality of both ends.

When you have dedicated testers in the team there is a risk that the developers have the attitude that they don't need to test their code thoroughly because someone else will test it for them.

Then the testers receive code with a bunch of obvious errors that could have been easily spotted by the devs if they just made some basic tests. This is obviously irritating. The developers get a bunch of bug-tickets and get defensive. Both are now irritated at each other, and the irritations grow stronger and stronger, every week.

That's a worse case scenario though :) It doesn't have to be like this. Most of the teams I have worked in, developers take full responsibility of testing and we have no dedicated test resources. In my experience this increases the quality and speed. And less irritations!

I think everyone's just trying to do their job and make sure the product is good.

Testing is a very vital part of every product. An engineer's job is to write code. The tester's job is to find bugs. The PM's job is to assign a priority to those bugs and the engineer will get to it based on the priority. It's just business.

I see no reason why engineers and testers can't have a beer together at the end of a day's work.

I've worked in companies both with and without friction between developers and testers. Friction is, more often than not, a result of developers doing a poor job and not checking their work before sending it to QA.

This can be mitigated by the dev team as follows:

• Always make changes in a new branch so that poor quality code doesn't snowball.
• Always have your code peer reviewed before submitting it to QA. (It is up to the team leader to ensure everyone regularly contributes to peer code reviews.)
• Always include unit, functional, and/or integration tests with your code. (They should be peer reviewed with the rest of your code.)
• Use a continuous integration system (e.g. Bamboo, Jenkins, Travis, etc.) to ensure broken branches cannot be merged.
• Don't merge your branch into the mainline branch (typically develop) until after it has passed QA, so that your change can be tested in isolation.
• Regularly version your mainline branch and, before doing so, have all changes associated with the upcoming version regression tested, in case any of those changes have an impact on each other.

It also helps to have a dev team with strong leadership and no incompetent devs.

I personally believe (in my experience), that developers who hate testers have huge egos. As much as I (as a programmer) can think of all possible scenarios - it is up to the tester to actually prove me wrong. IF the testers has managed to break my code - I have to yield and fix it because I am at fault.