在最后一轮测试中发现太多错误时，将采取什么策略？

#1 楼

这取决于

我在这种情况下经历的次数超过了我想起的次数，而且我使用的一般过程是这样工作的：



将所有发现归类-在这个阶段，我将把所有错误发现归为4类：



阻止器-任何使产品无法执行的错误基本的用户接受度测试，或破坏关键功能。这类错误的种类包括无法使用正在开发的功能，每次尝试访问新功能时应用程序崩溃，实际上无法在网上商店中购买任何东西等。严重破坏了整个软件。

严重-任何其他发生生命危险，影响很大的错误。财务计算不正确，主要安全漏洞也是如此。它们不会阻止用户，但会带来严重的负面影响。

中等-可能会发生的错误，如果发生，将导致尴尬和/或昂贵的后果，但不会违反任何法律或法规。会导致严重的阻塞问题。

次要问题-任何不属于其他类别的问题-这些都是可以等待的错误。



报告经过分类的发现-这是面临挑战的地方。一旦您和您的团队就所报告的错误的状态达成共识，就需要向上级提供简短的发现摘要。我更喜欢以下格式的格式：



阻止程序数量-当前未解决的阻止问题数量。我经常用红色粗体字给出这个数字。

严重错误的数量-再次，这是尚未修复的错误的数量。发布状态-为此，我通常使用三色系统。我认为红色表示没有释放阻止者就无法达到目标截止日期的情况。黄色表示截止日期是可能的，但存在风险，并且可能发布了严重的错误。绿色表示所有目标均已发布，没有任何阻止程序或严重错误。我通常会在知道目标版本存在风险后立即开始每周发送一次。在发布前的最后一周至2周内（取决于情况有多糟），我每天都会发送该消息。



上报调查结果-我的分类调查结果的第一位接收者通常是我的经理。如果我看不到要修复阻止程序的任何尝试，那么我将开始包括我经理的经理。升级时间表取决于发布时间表以及情况有多糟。我一直升级到公司首席执行官，最终迫使该特定计划的发布成为Beta版（存在合同要求）。 />
我们没有执行/不执行权限。可能有合同规定的要求在特定日期发布。
我们不是管理员。我们的职责是告知其他人我们测试的系统状态以及我们认为发布该系统可能有多大的风险。
坚持事实并保持简单。通过提高对问题的认识，您可以被视为麻烦制造者。您可以根据对公司的风险来确定调查结果，以限制强烈反对。

#2 楼

首先，这是一个管理问题，而不是测试本身。其次，这里没有正确的答案，这完全取决于上下文，也许发布糟糕的产品是可以接受的，也许是安全性至关重要的产品，您必须尽快停止它。因此，请将尽可能多的信息收集到一个易于理解的仪表板/演示文稿/内容中，然后将其呈现给您的同行-在这种情况下，可能是开发人员，开发人员经理和产品经理等其他相关角色。

会议的结果可能是忽略问题（请参阅下一段），或者是像您建议的作战室会议，或者只是推迟交货期限。会议，如果您有权拒绝构建（这是一项管理决定，有人信任您和您的判断），则继续并拒绝构建。

#3 楼

开始专注于错误预防，而不是错误跟进和扑救！已找到错误？”，“为什么我们当时没有捕捉到该错误？”，“我们应该怎么做才能防止此类错误/如此之多的错误？”可能的答案是：“开发人员应该在开发期间编写更多的单元/集成测试”或“让我们开始做/做更多的测试驱动开发”，“规范应该更明确/更少歧义”，“我们需要更好的日志记录功能”，“当事情还不清楚时，我们需要提出问题。”等等。重复一些其他重复出现或有趣的错误。繁重的过程。但是，如果您专注于一些错误并提出相关问题（例如我在上面建议的错误），则可以将其转变为一个轻量级的过程，所有相关方都可以从中受益。

#4 楼

我同意凯特的回答。我们需要对最终可接受的错误计数进行分类，找出关键的阻止程序，然后与所有利益相关者一起进入作战室，并确定执行或不执行决策要达到的可接受计数。

是的，测试是不负责任的，但是他们必须确保质量，并且他们的决定会影响交货时间。

#5 楼

为此，在进入解决方案之前，我会为以下问题而奋斗：

为什么测试人员在直接进行测试之前不进行烟雾测试？每个人都知道软件中的80％的问题是由于20％的错误引起的，所以每个人都必须相应地确定任务的优先级，以控制犯罪现场，以便某个地方出现问题。就没有错误。

好吧，让它。解决这种情况的唯一解决方案是让QA测试人员有足够的时间来完成其工作，以关注功能的各个方面。其次，您可以通过雇用一些专业的自动化测试人员来获得自动化技术的帮助。它们将简化并折叠整个场景。

#6 楼

为了避免在以后的阶段中出现过多的错误，可以很容易地处理不同的情况：


如果管理层知道应用程序很复杂，则应放宽时间表以进行质量检查团队可以获得足够的时间进行测试。
使用自动化测试服务来自动执行重复性场景。这将使职能工程师的工作变得轻松，并使他们能够专注于新的场景。 br />