更重要的是，从现在开始的一个月后，我可能会得到解决“项目12345引入的错误”的规范。好吧，天哪，我确定对此做了很多测试，显然我错过了一些。现在，开发团队是一臂之力，因为他们是引入该错误的人。我愿意承认我没有编写完美的代码，团队中的人也是如此。但是，您如何与一个（有偏见的）测试小组打交道：1）不与其他测试人员交流，并且2）拒绝接受他们在测试中也错过了这一事实的事实？这是一个非常不理想的环境。我们中有些人过去曾取得过相当不错的成绩，并希望使我们的部门尽快掌握最佳做法。这是一个缓慢的过程，有时我们甚至不确定从哪里开始。
#1 楼
几年前，我曾处理过同一问题。坦率地说，由于此问题的一部分是个人诚信，因此企业问责制只能走得那么远。作为一个现实主义者，我承认加强问责制确实有帮助，但只是暂时的。一旦个人意识到他们可以摆脱大量的误解，错误和模糊的规定，他们就不再保持高度的职业道德诚信。我认为该公司真正提供了帮助的唯一一件事是，他们调换了业务分析师和质量检查团队成员，由BA担任QA，然后由QA担任BA。我喜欢工作中的各种变化，因此暂时转职并不会打扰我。因此，一位BA尤其大大改善了她的规格和客户沟通。评论
@Laura感谢您提供的见解（此处|其他帖子）。如果广管局和质量检查人员...是同一个人，您会有什么建议？即广管局负责他提交的每个项目的质量检查职责。
–corsiKa♦
2011年5月6日21:26
回到我提到的现实主义观点（它对我有用，对我不利）。我将从尝试对这个人强制执行问责制开始。明确放下期望，以平衡所有人。 （可能因每个人的期望而异。）然后进行专业的监控和交流。希望仅需几个示例。 （自我说明：在传达这些差异时监视情绪。）所有情绪均已删除
–劳拉·亨斯利（Laura Hensley）
2011年5月6日在22:04
@劳拉我会尽量记住这一点。担任这些职位的大多数人已经在公司工作了10年以上，并且...有很多朋友，这是不幸的情况。我想这就是更多避免情绪激动的原因。但老实说，我不只是想要一堆CYOA；我真的只是希望这些项目能够完成并正确完成。您的期望确实因人而异。最近的评论中有一些重要的关键字；再次感谢！ :)
–corsiKa♦
2011年5月6日在22:09
它不会让我编辑先前的评论；我想我的思考时间超过了5分钟。这是我的修改后的评论：@glowcoder要澄清的是，作为BA的这个人缺少关键要素；然后，当他们开始质量检查（BA）差的功能（请原谅我周五下午5点的捷径）时，覆盖范围不足会导致质量检查质量差？那么，在这种情况下，他们本质上是自己最大的敌人吗？他们否认了吗？抱歉，在我假设/假设做错事之前需要澄清。
–劳拉·亨斯利（Laura Hensley）
2011年5月6日22:11
OK Glowcoder，已阅读您的回复。请原谅我学习stackexchange的缓慢。最良好的祝愿！
–劳拉·亨斯利（Laura Hensley）
2011年5月6日在22:12
#2 楼
我认为有人需要与管理层进行坦率的对话。这些人并没有进行质量检查/技术意义上的软件测试。他们正在进行用户验收测试。简而言之，您不能指望参与项目设计的人能够成功展示产品如何失败的真实愿望。这不是测试人员自己的错，而是谁决定担负BA角色/规范开发人员的人员也可以有效地进行测试，而无需任何其他专用测试的错。管理层需要了解测试人员对项目的最大价值在于他们的全心投入，表明他们正在测试的特定产品不能按预期工作。他们是团队中唯一一个致力于展示事物可能如何失败以及他们的失败导向需要得到保护的角色。让测试人员在定义产品时也起主要作用，破坏了这种失败的倾向。测试人员在制造产品时应采取的唯一作用是指出漏洞，不清楚的区域，客户需求与实际规格之间的不匹配，当前设计的潜在更好替代品以及其他故障或危险区域。一旦一个人开始为实际设计提供帮助，他们就会在情感上投入成功，而不会倾向于发现失败。
#3 楼
可以问他们是否认为他们可以对自己测试/签发的代码负责（如果这在您的组织中是必需的）。尽管您作为开发人员可以很好地测试您的代码，但是您对此也会有偏见，这是正确的。最后，参与该过程的任何人都应该至少对产品承担一些责任。不确定实际进行了多少测试，但是，您可以询问是否可以与他们坐下来，向他们展示一些有效的功能测试方法（当开发人员询问他们是否可以使我的生活变得更轻松时，我个人很喜欢）。关于测试人员或团队中任何人之间的交流，总是可以尝试就工作氛围进行对话，并最终询问交流以及您的看法。过去在查看几乎没有团队的团队时，这对我有用。有时是由于团队成员之间的敌意，有时，我完全错了，他们之间实际上沟通很好，但是由于公司的氛围，并没有公开显示。
评论
标题似乎无法很好地描述问题。也许“您如何与对改进不感兴趣的团队一起改进测试？”看来您的问题不是您的测试人员要做的不仅仅是测试，而是他们没有真正进行测试，只是简单地进行一下操作。@testerab关键点在于它们不仅可以测试，还可以生成项目的规格和功能要求。因为他们的主要目标是使项目完成，从而使满意的人满意，所以他们通常会忽略测试其他受影响的领域，从而有可能破坏其他人的工作。他们作为规范编写者的偏见是该问题的主要关注点。
啊-好的，现在我知道你来自哪里。