免责声明：我作为一名程序员正在处理这个问题（他来这里主要是为了学习如何更好地与我们的测试人员互动。）

重要的是要记住，开发人员并不总是被告知如何测试代码。尽管我们希望这不是真的，但开发人员从一个真正不关心系统各个方面的人那里得到了一组要求。您不能期望每个开发人员都了解系统的每个部分。

因此，开发人员获得了规范，记下了（提供给他的）要求并确保满足这些要求。不幸的是，规范中没有其他两三个要求是预先存在的，现在被打破了。

是谁的错？它是打破现有要求的开发者吗？还是生成规范的人只告诉他要测试什么？老实说，在许多公司中，甚至没有告诉开发人员他们需要测试什么。

现在，对于作为开发人员的我个人而言，如果您告诉我一种可以更好地测试一段代码的方法，请告诉我。如果我能阻止虫子看到你，我想这样做。否则，我必须在三天后修复它，当更改过滤到您然后返回给我时，我已经忘记了关于它的所有内容，我需要一个小时来完成一个应该的简单修复当我运行该测试时，我花了 30 秒。

所以你可以通过给他们建议而不是命令来告诉开发人员他们没有测试他们的代码。您可以说“嘿，我注意到出现了一些具有 XYZ 属性的补丁。通常，我使用_ _input 测试它们并以这种方式捕获很多错误。” 我认识的大多数开发人员都希望避免在代码发布后返回并修复他们的代码，并且会接受这一点。

我向你保证，如果你对此持对抗态度，你会得到一个非常愤怒的开发人员，他会大发雷霆。在这种情况下，你会说“你有错误的代码”而不是说“嘿，这是一种更高效的方法”。后者更具吸引力和生产力！

过去，我通过首先定义预期的“质量标准”并得到整个团队的同意来解决这个问题。这包括为整个团队设置缺陷阈值（通常每个开发人员 0 个 Sev 1 和 10 个错误）。当开发人员或团队超过此阈值时，他们必须停止添加功能并修复错误。

有了这个，它就为应用程序设定了商定的质量目标的期望。然后开发人员知道他的目标是什么。

然后，我使用指标和集中测试来强制执行此操作。如果开发人员或应用程序的某个区域容易出现缺陷，我们会将测试集中在那里，达到阈值并且开发将停止，直到质量得到提高。

开发人员首先讨厌它，但他们逐渐渴望使用高质量的代码库，因为他们可以自信而快速地添加新功能。

如果可能的话，和他们坐下来，解释错误。解释你是如何找到它的，并在他们说它已经准备好之前询问他们运行了哪些类型的测试。开始给出一些建议。我一直发现，以一些礼貌的、建设性的反馈开始代码质量讨论会产生最好的结果，让他们决定他们认为什么是足够的。并不是他们不想提供高质量的代码，有时他们只是不知道要寻找什么。

我的建议是将它们写在您使用的错误跟踪系统中。如果您没有，则需要开始使用。如果错误如此明显，那么他们的项目经理应该与他们交谈。跟踪软件的统计数据应该能够支持您的论点，即他们粗心大意，或者需要更好地了解该软件旨在解决的业务问题。

“明显”的错误有多明显？我的上一家公司在税务/财务报告领域销售软件。当我离开时，我只在那里呆了 5 年（其他人都比我待的时间长），许多“显而易见的”领域知识规则和测试是我还没有遇到的东西。一个示例规则是 5500 表格文件可能有附表 I 或附表 H 附件，但不能同时具有两者（两者都不可接受）。每个人都知道，它唯一被“写”下来的地方是 IRS 和 PBGC 法规的深处。在我在会议中被召集（并感到尴尬）之后，我最终也学会了。

在以前的雇主那里，最接近错误报告的是在走廊上大喊“在签到之前更好地检查你的工作！” 仍然没有回答出了什么问题。但是后来那家公司缺乏源代码控制，所以最后一个编辑文件的人要为该文件所做的所有错误负责。

我的观点，我确实有一个观点，就是对你来说显而易见的事情对其他人来说可能并不那么明显。