Without doubt conflict is avoided best by all concerned feeling that they are part of the same team. I recall working with a design team here in the UK where they and the FT team were deliberately sitting down and debriefing everything at the end of each days testing - usually in a quite informal environment. The result was that everybody felt very much to be part of the same team and all recommendations and technical discussions were very much directed at a combined desire to get the product absolutely right.
Less satisfactory is where the design and assessment teams are geographically separate (sometimes in different countries) and this sort of close relationship becomes very hard. In that case, what becomes important is that all negative findings are kept as private as possible. If deficiencies are not in the public domain, then ego and face saving is not too much of an issue. Often then it is possible to become public about the problems after they've been solved, because everybody involved feels good about being part of producing a good aircraft - if problems become too public before they're solved people start digging in and a solution acceptable to everybody becomes increasingly hard to solve.
Where it really goes wrong is where the project management system doesn't allow close liaison with the design team. Some years ago I was busy testing a British training aircraft with an American engine. We found a quite serious problem with the engine installation. The system we were bound by required me to report my problems to my management, they then reported them to project management office on another site, they then went via a regional office in the US and finally the American engine manufacturer was informed. Unsurprisingly, the Americans dag their heels in and denied there was any problem - with half the industry knowing about the problem before them one can hardly blame them. It got solved eventually, but took months longer than it should have done and caused a fair bit of ill-will and unnecessary 3rd party testing in between.
So yes, even project management have a part to play - in large part by ensuring that FT and design are talking regularly without delays or political filtering of the information. It's hard for a project manager to grit their teeth and realise that the best way to manage is by allowing relevant experts to communicate directly and monitor what they are doing, rather than trying to act as intermediaries - but that is the best way particularly in this particularly thorny scenario.
Finally there is a tendency amongst flight testers towards a rather arrogant "we are the experts and know best" attitude. When dealing with some project managers this is understandable (it does in some organisations tend to be a "Peter Principle" sideways move position). However, we must be absolutely prepared to justify, in whatever terms our audience needs, all of our conclusions and recommendations. Practices such as omitting data that contradicts the conclusions, changing graph scales to make a case seem stronger than it is, trying to blinding an audience with science, have no place - but I'm willing to bet we can all think of instances of any of them.
G