Answers:
我认为这是过度概括和过度简化的结果。
我目前是一名测试人员，我编写的代码几乎与开发人员编写的代码相同（取决于测试阶段），并且我公司中最好的朋友是一名开发人员，我们都相处融洽。
您可能想看一下公司的文化以及团队相对彼此的工作方式，以找到答案。以我的经验，如果您有非常反动的工作流程（例如，开发人员“将构建扔在墙上以进行测试”和测试“将错误扔回去”）而不是一起工作，而只是从不同的重点或“攻击向量”出发，我会发现，两个部门总体上都会彼此不喜欢。
在我工作的地方，每个功能团队或设计团队都有几乎与开发人员一起工作以产生输出的测试人员。该输出是符合测试代码规定要求的生产代码。
编辑
另请注意，我认为测试者的责任比支持两者之间关系的开发者要多。
对我们来说，使开发人员的生活变得更好或更糟要容易得多，但是目标不仅是“发现错误”，而且是找到潜在的解决方案。如果我不能，我不能，我会与任何人被分配了一些bug，在这一点上找到一个解决办法。但是，如果这是一个简单的解决方案，那么我将提供我认为是可以满足各种要求以及最终编写的回归测试的潜在修补程序。
我喜欢我的测试人员-他们可以帮助我进行故障排除并找出我认为不会出现的问题，但我们的客户会发现。对我来说最重要的是，它们可以帮助我确保我不会杀死使用错误代码的人。
为什么会弹出问题？
结合以上这些以及职位的性质，这很容易使您当前的愤怒和挫败感相互消除，如果您陷入了陷阱，那么您将停止共同努力，开始彼此对抗。这很难突破，对任何人都不利。
我猜想是因为程序员创建了一个程序，然后他们认为测试人员会尝试发现其中的缺陷（即使测试人员实际上是改进最终产品的一部分），也会发生这种情况。每当有人发现您要付出很多努力的缺陷时，对它们做出消极反应可能是自然而然的反应。
减轻这种情况的方法是使开发人员和测试人员将完成的产品视为整个团队（包括测试人员和开发人员）的输出，并使他们理解测试不是独立的故障发现任务，而是测试的重要部分在发展的过程。如果开发人员认为测试不是一项真正的工作，或者觉得这很简单，请让他们编写测试矩阵，执行数百个测试用例，记录每个步骤和每个结果。
在与测试人员紧密合作的团队中，我们的合作非常顺利。测试人员了解制定各种决策的决策，了解开发人员的进度表，并在两组之间建立融洽的关系。
在测试是离岸一些无定形实体的团队中，情况并非如此。测试人员的结果不太重要，因为他们对正在发生的事情一无所知，开发人员开始对他们认为是无关紧要的细节泛滥成灾，这些细节在程序的某些部分中并未被两部分涉及几个月以来，测试团队很生气，没有解决所有已提交的错误（因为排定了时间表，并且开发人员正忙于准备进行演示或添加请求的功能等），并且总体而言，这两个团队将彼此视为对立的与团队成员相对的“其他”。
密切合作，一切都会好起来的。有人需要确保两个团队的协调并在同一页面上。我最好的经验是，测试团队被邀请参加开发人员团队被邀请参加的所有高层会议（所有人），我们都知道时间表，我们拥有统一的优先级列表，并且开发人员和测试都具有相同的（向上-迄今为止）的需求文件。我最糟糕的经历（除了没有测试），我们基本上打包了东西，运往国外看，然后在一个月后拿回了所有东西，但标记为错误的东西甚至都不是我们的（满足新要求的第三方插件）要求，而不是测试团队的期望）。
如果没有开发者或测试者，没有其他任何人都不会成功。如果您像同一台机器的两半一样工作，并且尊重对方，就像尊重更直接的团队成员一样，那么一切都会好起来的。表现得像两台单独的机器，并假设您的机器更好，那么情况将会很糟糕。
当程序员和测试人员彼此不喜欢时，通常是因为他们错误地认为他们的目标冲突。
我发现，当测试人员和开发人员位于同一团队而不是“测试团队”和“开发团队”时，这些问题将大大缓解。我认为这就是为什么作为一名测试人员，我非常喜欢在敏捷团队中工作，而不是瀑布开发。有了更多的沟通，周转更快，并且当工作更加透明时，开发人员对测试所需的时间和才华有了更大的了解。
单独地，还有很多事情可以做。作为一名测试人员，我发现我可以通过提供积极的反馈以及发现错误来减少这种摩擦。我还没有为一个不能教我很多知识的开发人员进行测试，我发现开发人员非常感谢真正致力于理解代码的测试人员。开发商都感到骄傲，就像好的工匠。重要的是要让他们知道，拥有bug并不能使他们变得不那么令人钦佩
我发现最容易以满意的高质量工作的开发人员，并通过在测试人员看到之前努力编写高质量的代码来进行演示，包括进行初步测试（主要是自动单元测试和手动烟雾测试）。这些开发人员还要求测试人员进行代码审查以确保其可测试性，并尽快将测试人员纳入流程，包括尽早向他们提出设计（这使测试人员可以在测试工作量较小时开始及早计划测试策略）。开发人员可以告诉测试人员匆忙开发了哪些区域，或者哪些区域难以进行单元测试，从而可以帮助测试人员找到代码中的薄弱环节。总的来说，开发人员可以使测试人员的工作更轻松的任何事情都受到赞赏，并表明他们珍视测试人员的时间以及自己的时间。当开发人员这样做时，
另一个问题是，质量保证通常是许多公司的后遗症。很多时候都在最后一刻被告知有关项目的信息，与开发团队相比，人员配置严重不足。在某些地方，开发人员的途径是技术支持，质量保证，然后是开发人员。所以有时会有希望他们是开发人员的人来工作...然后当他们发现缺陷时，他们的态度就是那个人如何成为开发人员，而不是我，我永远不会犯这样的错误，等等。
总的来说，我会喜欢QA团队。我也认为单元测试应该是软件开发中与质量保证分开的必要部分。因此，当质量检查人员发现错误时，单元测试就会更改为对此进行测试。另外，我认为进行单元测试的开发人员可以更好地理解QA的发现。
另外，许多质量检查团队必须手动执行操作，在这种情况下，这确实很无聊。在某些地方，QA编写脚本并使用自动化程序，甚至允许编写GUI脚本（通过屏幕上的按钮/等图像识别）。然后，当首先进行重大更改时仍然很困难，但是随后一切都实现了自动化，并且看起来更加有趣...
另外，一些开发人员也不愿接受质量检查。不过，我还是希望质量检查人员比客户发现缺陷。
作为开发人员，我经历了与测试人员的紧张关系。
在一项工作中，测试人员很少会测试“正确的事物”。我将为产品的服务器实现一项新功能，测试人员将报告有关用户界面的全部错误。由于在该产品中，用户界面未配置为未编码，因此我们开发UI中是否存在问题与最终用户是否具有类似问题的UI绝对没有联系。测试人员知道这一点，但是仍然坚持记录有关无关区域的错误。
就是说，好的测试人员值得在黄金中投入重金-我马上就将一个糟糕的开发人员换成一个好的测试人员。优秀的测试人员是提供优质产品的合作伙伴。
我还知道一些将测试人员视为敌人的开发人员-好像测试人员正在引入错误。对于开发人员而言，重要的是要意识到测试人员永远不会引入错误-他们只是发现错误。
不好的感觉通常是沟通不畅的结果，这通常是程序员和测试人员对代码有不同看法的结果。程序员知道他一直在紧密地工作，但是可能不知道它们如何适合整个系统（超出了规范的范围）。测试人员可以看到全局，但并不了解详细的代码。这些小组可能对同一事物使用不同的术语和程序。
这可能导致将错误提交给错误的组件（因为该组件正在响应上游的故障），或者开发人员关闭了合法缺陷，因为他们无法在其环境中重现问题（因为他们并不真正了解如何重现）问题正确）。如果这种情况经常发生，则可能会使小组之间的关系紧张。
然后很高兴在第11小时收到一批缺陷；截止日期迫在眉睫，连锁店的直属经理正面临着压力，您在知道自己已经解决的问题上又有了新的缺陷，您真的不想花时间去解决通过过程来证明这一点。
惹恼您的质量检查小组的一种非常好的方法是，立即关闭数百个合法但低优先级的缺陷（主要针对难看或不一致的用户界面，这些UI本来可以正常工作），其理由是您的高优先级缺陷积压很大，以至于“我们永远都不会去那些。” 在计划经理的电子表格上，您从红色变成绿色，并从上级管理人员那里获得了帮助，而QA团队则对他们的指标提出了要求，提出了一系列虚假的缺陷。
坏枣
我认为，如果确实如此，那是不成熟的迹象。有时您可能会把它当作一个玩笑。但是，如果您（从事同一项目的开发人员和测试人员）不觉得自己像一个团队，那么结果将是一场灾难。
测试是软件开发生命周期（无论是否敏捷）中非常重要的一部分。因此，您不应该将测试人员想象为那些会为您困扰的bug的人，而是将其视为帮助您交付高质量软件的团队伙伴。