如何关闭不再相关的错误

我目前在一个中型的Web开发人员团队中。我们正在使用jira进行错误跟踪。

我们正在开发频繁更改版式的产品。很多时候，在某些浏览器中都会提交有关布局中的错误的错误。有时，当我们开始处理低优先级错误时，布局已经更改，不再适用。

• 我们应该怎么关闭它？
  我的意思是我们应该如何对待这些问题？尽管Jira是我们使用的错误跟踪软件，但我对如何处理这类问题更感兴趣。
• 有关系吗 （我们可能稍后再返回布局，但这不太可能）

如果您将问题跟踪程序视为传达项目中报告的问题状态的一种手段，那么这种细微问题就很重要。为此，有必要付出一些努力来确保错误报告易于阅读和理解。

如果从测试人员的角度来看，这种情况就不会那么混乱了。如果你的团队没有一个测试仪，想象一个（或更好，但雇用一个^1，2，3）。

好的，所以曾经有一个错误，测试人员可以使用您的较旧版本的应用程序来重现它（注意，在不太可能的情况下，如果您不保留较旧版本的副本，那么您将遇到很多难题团队，而不是过时的错误）。测试人员可以看到它，并可以指出出什么问题了，是什么使它成为错误。

现在您说，“布局已经改变，不再相关” – 测试人员头脑中的高调不再相关，变成了更简单的说法：问题已经解决了。

• 重要的是在这里要注意，专业的测试人员应该将系统视为黑匣子。从这个角度来看，问题发生的确切程度并不重要，可能是布局更改，黑魔法或整体重新设计，或者具体的代码更改等。

从黑匣子的角度来看，您的情况非常简单。有一个问题，在较旧的版本中仍然可以重现，现在您声称较新的版本不再存在此类问题。对于测试人员而言，这可以归结为错误已修复的主张，以及需要验证该主张是否正确的需求。

专业测试人员会使用您的较旧版本，查看那里存在的问题，然后采用较新的版本并检查它是否消失或仍然存在。

从上面开始，处理您所描述的错误的最准确的方法是按已解决的，固定的方法将其关闭。当然，如果您在注释中明确指出此修复程序是布局更改的意外副作用，那也不会有任何伤害。

我曾经在过去的项目中使用过的一个定制JIRA，其分辨率为“ Fixed By Design”，可以传达相当深刻的变化，从而带来很多后果，有些是有意的，有些则没有。对于您所描述的情况，也可以考虑将其替换为普通的“固定”，因为它提示票证读者这更多是副作用，而不是有意的代码更改。

我们解决了“过时”等问题。这不是JIRA中的默认分辨率选项，但添加起来很容易。

JIRA（我敢肯定还有其他的错误跟踪器）允许您指定自定义解决方案，因此您应该能够设置“被事件超越”或“ Irelavant”解决方案，或者类似的设置来表达您想要的关闭方式

有关系吗？这取决于我们，我想说是，因为我们的客户过分担心跟踪器中的未解决问题的数量，因此对我们来说能够说出这些已解决问题很有用，因为在不再删除问题的情况下它们不再相关。

即使客户不关心问题编号，修剪不再相关的旧未解决问题对于减少浏览器的混乱情况也绝对有用。

我们使用FogBugz，但我确定此处适用相同（或相似）：

我们只使用“已解决（已修复）”并在分辨率中添加注释，例如“案例12345修复”。

FogBugz匹配“ case \ d +”并在“ Related Cases”下将两者链接在一起，但是如果Jira不这样做，则只需添加一个链接就应该很简单。

这是IMO比“ Too Localized”变体更好的原因，因为它是一个实际的错误，而比“ Obsolete”更好，因为它已得到修复，而该功能并未被删除。