让我们暂时放下所有的防御。为什么实际上没有发现缺陷？有时，“因为我有太多其他事情要做”实际上是“因为自己设定的任务优先级不合适”或“因为我的测试不够深入，无法找到那个问题”，或者其他内部你的控制。

在争论你有太多事情要做时要小心——这是一个你很少会赢的弱论点。每个人都有太多的事情要做，而没有足够的时间。每位经理都希望您了解什么是最重要的，什么是“值得拥有”。

相反，想想是什么让你在其他人之前发现了那个错误。也许更强大的理智测试，或更早的回归测试，或其他您可以控制的东西？

尝试以非防御的态度与管理层进行讨论，也许还可以提出解决方案。你的管理层会很感激的。

您可能要考虑的一件事是事先阅读 Gerald Weinberg 的“Perfect Software: And Other Illusions About Testing”。里面有一些很好的讨论点。请记住，管理层不会问你为什么软件不完美。相反，他们会问您为什么没有在软件的特定部分中发现他们（正确或错误地）认为您应该发现的错误。也许他们的感觉是合理的，也许不是。尝试深入挖掘并自己找出它们是否正确。

给定无限的时间和无限的资源，您永远无法找到功能或产品中的所有缺陷，可能有一些击键或条件的组合会导致问题，但并不总是可重现的。如果管理层希望您找到功能中的任何和所有缺陷，那么他们给您的目标是不切实际的，如果他们允许您通过调整您的测试来调整您的流程以捕捉缺陷，那么您可以不断改进并确保“这个”不会再过去了。

您可以向您的管理层解释，并使用发生的任何高调中断或缺陷，测试是一个自适应或进化过程。甚至 Microsoft 也会针对在其软件中不断发现的缺陷发布补丁，如果 Microsoft 没有发现所有缺陷，您希望如何？您无法找到所有内容，尤其是在执行多种测试类型和方法时，但您始终可以重新评估您的测试并改进您发现的内容。在这种情况下，如果缺陷出现并被其他人发现，请提出重要问题，为什么会错过？为什么要让不熟悉产品的人才能找到它？您可以添加什么测试用例来确保它不会再次发生？

最终归结为您的管理层是否愿意倾听您和您的担忧，并允许您的方法有效，但总是需要稍作调整以控制事情？

除了其他人所说的之外，还有一些其他因素需要考虑：

• 您的经理是否知道您的软件的复杂程度？鉴于您的团队被分配到产品的各个领域，听起来您需要支持一个高度复杂的软件，这意味着在物理上不可能捕获所有内容。如果管理层没有意识到复杂程度的影响，您可能需要提供一些示例让他们了解实际发生的情况。
• 您的管理层是否知道您和您的测试人员同事每天都在做什么？如果不是这样，这将是一个教育他们的好机会：如果他们将您的团队视为代码进入并（希望）质量出来的黑洞，他们可能会认为您每天都在创造奇迹（您可能做，但不是你的管理层认为你正在做的那种）。
• 你有“管理演讲者”吗？以我的经验，担任管理职务的人不会说与测试人员相同的语言。两者听起来都像英语，但是很多单词的含义不同。
• 您能否向您的管理层或您的演讲者向管理层解释偶然性和探索性测试的力量？根据您的描述，听起来发现的问题是您的常规测试计划不会发现或直到周期的很晚才发现的问题：这意味着其他人正在做某事，注意到一些奇怪的事情并认为“嗯. 这很有趣。我想知道如果……会发生什么？并发现了一个错误。正如您所认识到的那样，这是一件好事，但由于这不是一项计划中的活动，因此具有管理背景的人在没有一些引导和背景的情况下可能无法真正理解这种事情。
• 你能指出一个完整的时间表和一个在周期的某个时刻会发现这个问题的测试用例吗？虽然这是对您的解剖学覆盖，但您也可以使用这些信息来证明您的团队人手不足，因此任何人发现的任何问题都是对您的奖励。（我不知道是否是这种情况，但这是我目前正在处理的事情，所以我熟悉那个特定的论点）。

我希望其中一些建议有所帮助。

这似乎意味着您组织中的管理层希望 QE 团队成为看门人，因为它不应该成为一个责备游戏，即为什么错过了缺陷，而不是为什么首先引入它，并且团队集体调查它浮出水面的根本原因. 接下来是我们如何防止此类错误在未来渗透。