有人知道一个好的缺陷矩阵或缺陷管理过程吗？

Question

我目前正在寻找一个好的错误矩阵。有没有人知道，我遇到过这样的情况：https://michaellant.com/2010/05/25/a-simple-agile-defect-management-process/

Answer 1

您在链接中提到的矩阵调用范围，通常称为可见性或影响。否则，它是相同的，严重程度是混合影响和脆弱性。

像Michael在他的文章中所做的那样，我认为混入矩阵的严重性和优先级并没有额外的价值，因为这两个度量标准几乎没有什么不同的故事，因此我认为这是错误的。您可能会有一些but，这些but对用户来说只是小问题，但由于另一个原因(在下一次构建中存在修复程序、键用户等)，这些but非常重要。

优先级不应直接由严重性/影响/漏洞度量来确定，因为那样它就会变得毫无用处。

• 严重程度告诉您故障有多严重，损坏是什么，以及有多少用户会看到这一点。
• 优先级告诉你该如何修正错误(通常是涉众的愿望)。

看看我回答的问题，它是在早期测试版中创建的，目的是为SQAStackExchange提供一些内容：

• 如何分类缺陷？ --特别是Impact的严重程度矩阵(脆弱性和影响)和我对ISTQB标准的反应。
• bug严重性和bug优先级之间有什么区别？ -对于严重性和优先级之间的差异来说，接受的解决方案是最好的。

Answer 2

我建议不要使用bug矩阵，原因有二：

• 这比你想象的更主观
• 未能将缺陷与对客户的实际影响联系起来

我建议写一个高质量的故事代替。当然，如果你没有别的东西，只是在寻找优先修复bug的方法.没有解决的问题..。那么我可能真的同意错误的论点，那就是它总比什么都没有好。

我试图在StackExchange给出一个更明确的回应，但我还没有了解到不被分类的垃圾邮件的细节。我的详细版本是这里，如果您想知道为什么它是主观的，为什么它在这个任务上失败，以及一些关于替代方案的建议。

Answer 3

我是“零缺陷政策”的大力拥护者，以及它如何分类缺陷。在缺陷被引入之后，修复它们就容易得多了。

敏捷团队应该尽快从他们的反馈中学习。缺陷也是反馈，使用它来做一个根源分析后修复任何缺陷.这有助于找出如何防止类似的事情发生在未来。

我增加了第五个分类“关闭”的缺陷，不应该得到优先权，因为他们是微不足道的。确保你和你的记者清楚、公平地交流。