在我的公司，我们没有测试人员，确切地说。我们有分析师将业务需求转化为规范。（想想 Office Space 的那个人，除了这些人实际上提供了一些价值。有点。）因为他们有一个议程（让给他们要求的人高兴）他们经常缺乏他们所做的测试的彻底性。有时是因为他们根本没有考虑过一个部分，但有时是他们主动忽略了一个区域，因为他们知道如果他们测试它，它会损坏，或者如果他们测试它，他们不知道任何一种方式是对还是错。
更重要的是，一个月后，我可能会得到一个规范来修复“项目 12345 引入的错误”。好吧，天哪，我确实对此做了很多测试，显然我错过了一些。现在，开发团队是受到抨击的人，因为他们是引入错误的人。我愿意承认我写的代码并不完美，我团队中的人也是如此。但是你如何处理一个（有偏见的）测试组，1）不与其他测试人员交流，2）拒绝接受他们在测试中也错过了它的事实？
请记住，这是一个非常不理想的环境。我们中的一些人过去做得很好，并希望让我们的部门跟上最佳实践的步伐。这是一个缓慢的过程，有时我们甚至不确定从哪里开始。
几年前我处理过同样的问题，坦率地说，由于这个问题的一部分是个人诚信，企业责任只能到此为止。作为一个现实主义者，我承认增加问责制确实有所帮助，但只是暂时的。一旦个人意识到他们可以摆脱 x 数量的误解、错误和模糊的规范，他们就不再保持高水平的职业道德诚信。我认为公司做的唯一真正有帮助的事情是他们交换了业务分析师和 QA 团队成员，让 BA 做 QA，让 QA 做 BA。我喜欢工作的多样性，所以暂时不会打扰我。因此，特别是一位 BA 确实极大地改善了她的规格和客户沟通。
我认为有人需要与管理层进行坦率的对话。这些人不是在 QA / 技术意义上进行软件测试。他们正在进行用户验收测试。很简单，你不能指望参与设计项目的人也有真正的愿望来展示产品是如何失败的。这不是测试人员自己的错，而是谁决定填补 BA 角色/规范开发人员也可以有效测试，而无需任何其他专门测试的人的错。
管理层需要了解项目测试人员的最大价值来自于他们全心全意地展示他们正在测试的特定产品没有按预期工作。他们是团队中唯一致力于展示事情如何失败的角色，他们的失败导向需要得到保护。让测试人员在定义产品方面也扮演主要角色，这会破坏这种失败导向。测试人员在构建产品时应该扮演的唯一角色是指出漏洞、不清楚的区域、客户需求与实际规格之间的不匹配、当前设计的潜在更好替代方案以及其他故障或风险区域。一旦一个人开始帮助实际设计，他们就会在情感上投入到成功中，并且不太倾向于发现失败。
可以询问他们是否认为可以对他们测试/签署的代码负责（如果这是您组织的要求）。尽管您作为开发人员可以很好地测试您的代码，但您也会对此有偏见，这是理所当然的。最后，参与该过程的任何人都应该愿意至少对产品承担一些责任。不确定实际完成了多少测试，但是，您可以询问是否可以与他们坐下来，向他们展示一些测试功能的有效方法（当开发人员询问他们是否可以帮助我的生活更轻松时，我个人很喜欢）。
至于测试人员或团队中的任何人之间的沟通，总是可以尝试就工作氛围进行对话，并最终询问沟通以及您认为自己注意到了什么。过去，在查看似乎几乎没有的团队时，这对我有用。有时是因为团队成员之间的敌意，有时，我完全错了，他们实际上有很好的沟通，但由于公司的气氛，没有表现出来。