您应该关闭旧错误吗？

#1 楼

我想说产品负责人（或最终决定团队工作的人）可以决定某些错误由于某种原因或另一种原因无法修复。然后，我将关闭记录该事实的bug，以便稍后可以清楚地了解发生了什么。关闭它们，时间本身就不够好。

#2 楼

我想分别考虑每种情况：


低优先级-低优先级的bug并不总是保持低优先级。如果有足够多的用户抱怨（或者一个重要的客户提出了建议），他们总是倾向于成为高优先级。关闭似乎不是一个好选择。
极端案例-记住墨菲定律。这些往往会发生，而当您最不期望时就会发生。关闭它们不是一种选择。
业务优先级-即使业务优先级不同，错误仍然存​​在。如果新版本的软件是绿色领域，则这些错误可能没有意义-但仍需要进行验证。 >如您所见，在修复错误之前，我不打算关闭这些错误。我建议使用跟踪工具中的优先级和类别字段，并在需要时将其隐藏。输入错误需要花费时间和精力-关闭它们而不解决它们是浪费精力。

#3 楼

Bug是Bug，它有多老都没有关系。作为测试人员，如果开发人员尚未解决并由测试人员验证错误，则不应关闭该错误。

关闭旧错误而不解决，然后再次插入，这只会增加错误数。可以先集中精力于高优先级的bug，但是没有解决就关闭似乎是错误的。

但是，如果该错误来自于已被删除或完全更改的需求，那么测试人员可以书面形式获得客户的认可，由于该需求的变化，特定的错误是没有意义的，我们应该关闭该错误。这样就可以关闭。

#4 楼

以我的经验，仅仅因为它很旧就关闭bug并不是一个好主意。我的组织曾经将其作为一项策略来执行，但是却引起了许多问题。测试团队将运行查询，以查看在两个版本之间关闭了哪些错误。如果关闭了错误，则该测试用例将不再运行（因为假定该问题已解决），直到下一个主要发布周期为止。这导致旧的，通常是低优先级的错误经常消失并重新出现。对于经理来说，这甚至看起来就像您的团队一次又一次地犯同样的错误。如果再次遇到问题，将提交一个新的错误，但是新的错误报告未与原始错误报告连接。对于很少了解或很少复制的错误，您需要获取所有信息才能对其进行调试。向现有错误报告中添加更多信息通常比为同一问题提交第二个错误报告要更有效率。对于大多数大小不小的漏洞跟踪数据库，提交者手动挖掘所有已关闭的漏洞以寻找可能的匹配项是不切实际的（很难让他们查看打开的漏洞）。 br />可以鼓励人们忽略问题。是否有不是关键任务且解决方案特别困难或不受欢迎的问题？只要将其忽略足够长时间，它就会自行消失。这绝对不是您要鼓励开发人员去做的事情。

隐藏问题几乎总是一件坏事。比留下一百个老错误更糟糕的是，使一百个您不再意识到的错误。这几乎可以保证它们永远不会被修复，也不会阻止您再次犯同样的错误。

一段时间后，我的小组重新评估了我们的政策，并确定这会使情况变得更糟，而不是更好。我们更改了政策，以便不关闭旧的缺陷，而定期召开会议（在每个主要项目版本/里程碑结束之后），在那儿我们重新评估超过一定年龄的缺陷。这帮助我们了解了为什么这些旧错误首先存在，以及为什么它们能够坚持这么长时间。他们中的许多人最终被拒之门外，但是出于特定的有意义的原因（例如，错误报告没有足够的信息来开始调查，测试用例不正确，或者因为相关功能已被取消并且问题现在已经解决）而不是仅仅因为他们老了。经过几轮之后，我们的组织在识别这些类型的错误并更改我们的流程方面变得更好，这样一来它们就不会被归档。我们实际上能够解决积压的大错误，而不仅仅是将其隐藏。

所有这些都围绕着大问题进行。如果您创建错误的速度比修复错误的速度快，那么您将面临重大问题。您确实需要重新评估您的开发实践，并确保随着时间的推移您在提高代码库的质量，而不是使其变得更加麻烦。如果您有很多错误的优先级较低，可以在很长一段时间内忽略，那么这也可能暗示您的测试计划将重点放在错误的地方。

#5 楼

我不会关闭错误-您可以“停放”它们-但看起来错误似乎无法解决。
在我们的软件发布周期中，我们有大约2个月的错误修复阶段-在此阶段，大多数开发人员只修复错误，没有新功能。这使我们摆脱了大多数低优先级的错误。并使产品更加“全面”。

最终可以帮助您运送更好的产品。

#6 楼

我认为想出一个解决缺陷的好策略是非常明智的。

我曾经在一个拥有3000多个主要，次要和琐碎错误的团队工作，其中大多数错误在跟踪系统中至少存在2-3岁。有一次我们想开始清理并开始修复它们。结果是数小时的时间浪费在写得不好的缺陷报告上，因为它已经修复和/或没有正确描述，我们无法复制。

正如永无止境的特征列表可能会令人沮丧一样，长长的缺陷列表也会如此。您不想一次又一次收到有关您不久将要修复的项目的警报。找出未来2-3个月需要关注的重点，并做出相应的计划。

始终保持阻塞和严重缺陷，但要决定是否要修复主要-临时缺陷在发布周期内将它们存档。没有缺陷）团队可以交付。

#7 楼

关闭错误时，应该有关闭错误的原因。最明显的当然是已修复，但无法复制，不是错误，也无法修复同样有效。遵循了重现该错误的步骤（您的错误报告中确实包含这些错误，对吗？），但无法使该错误在其开发系统上发生。这种状态并不意味着该bug不存在，而只是意味着该bug发生还有其他步骤或条件。例如，我有一些仅在非常特定的温度条件下发生的错误。如果此错误很重要-请参见下文-那么它需要返回测试人员以找出真实条件。设计。在测试游戏时，您经常会看到这种情况-测试人员认为应该发生一些不同的事情，但这不是设计文档中的内容。测试人员可能是正确的，但是测试通常是进行重大设计更改的错误时间。

Will Not Fix与之类似，但不是作为设计工作，这是一个较小的问题，不会严重影响大多数用户。

请记住，并非所有bug都是一样的。在每个平台上启动时崩溃的那些优先级最高，而在异常情况下导致无关紧要的图形故障的优先级则要低得多。程序员需要根据他们的优先级集中精力修复错误；随着时间的流逝和可怕的出货日期的临近，所有类型的错误都将置于“无法修复”状态。这些错误可能会在以后的补丁程序中修复，但暂时不会修复。

那么谁来分配优先级呢？最初，测试人员将使用某种形式的清单或标题。接下来，质量检查负责人和编程负责人应在最终确定分类并将其分配给程序员之前，讨论新的错误。优先级不固定；额外的测试可能表明这些错误或多或少是严重的，或或多或少地频繁发生。而且，当然，随着交付日期的临近，一些错误似乎远没有那么重要了。

一旦程序员解决了一个错误，它仍然没有被关闭。如果已将其标记为已修复，则必须返回质量检查以确认已修复。无法重现可以重做更多测试，或者在不重要的情况下静置。通常，没有bug时需要确认其是否按设计工作，而通常需要一些确认才能得到修复。

#8 楼

这个问题有两个问题：如何使用错误跟踪系统，以及如何处理过多的错误。在您的错误跟踪系统中显而易见；这些系统在反映现实时效果最佳。任何体面的错误跟踪器都可以让您记录该错误是由于已修复而已关闭还是由于您选择忽略而已关闭。

有很多原因可能会导致您的错误超出开发人员的能力。某些原因实际上是软件问题（例如，开发人员编写了太多的错误）；有些可能不是（例如您的测试人员挑剔，或者许多错误是重复的，或者许多错误是误报。）不同的组织（在不同的时间）对错误的容忍度也不同。如果您的产品有太多错误，您的用户会告诉您，并且您会意识到需要进行一些更改。

#9 楼

如果发现的错误多于已解决的错误，那么
不断扩大的错误队列应该怎么办？ br />早于x天，因为如果仍然是问题，它们将被重新提交。

如果“关闭”表示“我们不再需要查看该错误”，则您必须假设下次进行重大测试时会弹出相同的问题。然后，某人（测试人员？）将不得不决定“我应该提交新的大报告，重新打开旧的报告，还是完全忽略该问题”。这三个选择中的每一个都有问题。

寻找与“已关闭”不同的状态。您的错误跟踪系统中可能存在“延迟”或“以后”。这些状态可能表示“我们知道该错误，不会在此版本中对其进行修复，但将为下一个版本重新尝试”。那将是我的偏爱。

然后，花一些时间来诊断为什么有这么多未修复的bug，并为该问题寻求解决方案。

#10 楼

尽管是极端情况或低优先级，但如果您仍然可以重现报告的错误，并且该系统的预期功能仍然表明它是错误（而不是仅是不再有效的旧要求），那么它仍然一个错误，应该这样处理。

我不会说QA负责维护产品积压的责任（产品负责人会这样做），但我认为，有效的错误仍然存​​在在修复之前，始终是一个有效的错误，并将这些项目留在待办事项中可以很好地了解被测软件的总体状态。