您如何在错误跟踪器中执行或维护错误报告的质量？ [关闭]

Question

高质量的错误报告对于有效的错误跟踪至关重要 - 在理想情况下，所有错误报告都将包含基本信息，例如它影响的软件版本以及如何重现错误的分步说明。

但实际上，报告的错误质量可能相差很大。他们可能是在线的（“功能 X 不起作用，修复它！”）、功能请求、PEBKAC 或无法理解。

您如何执行或维护错误跟踪器中错误报告的质量以保持有效性？

Answer 1

使用UserVoice 之类的内容供最终用户报告错误和功能请求。错误跟踪器条目确实应该是内部的——它们对最终用户来说太技术性了，而且恕我直言，暴露了太多的内部工作。

Answer 2

我曾经认为错误报告的质量无异。我仍然这么认为……我报告的错误比 QA 或操作输入的错误包含更多有用的信息。然而，我开始欣赏 FogBugz 的模型。输入错误非常简单。即使没有很多支持信息，只要知道存在错误情况就会很有帮助。此外，用户会觉得某事正在完成。

Answer 3

编写一个很好但不太长的教程，介绍如何使用跟踪器以及每个字段的要求。制作一个通用参考示例，其他人在遇到困难时可以使用。

我有一份用于编辑 Docbook 手册页的参考副本，通过反复使用，我已经牢记大部分语法。

Answer 4

棘手的问题。我会尝试看看系统是否有任何方法可以强制输入您需要的某些字段，尝试以某种方式（电子邮件，rss）让任何重要的错误出现在您的眼前，这样您就可以快速突袭，但主要是您的团队了解并遵守质量标准，发布和公开指南，诸如此类。

假设是您的团队： 如果您可以在 cmets 字段中每次都使用某种结构，当输入它时，那将是预期的，那么这也很好 - 如果您的软件有一个默认注释大纲，您可以在其中定义该结构，那就更好了一个空白表格。

不过，在某种程度上，这取决于个人，他们必须意识到这是沟通标准的一部分，是工作要求的一部分，而且他们要对团队中的所有其他成员负责 - 因为其他如果可以避免的话，人们不应该追捕他们以找出任何进一步的细节。

特别是因为修复低优先级项目的错误的周转时间可能需要一些时间，而且人们肯定会忘记细节。

假设它的用户： 你不能达到很高的程度，但我会尝试 - 如果可能的话，以人们可以理解的方式提出任何形式的问题。

不完全是关于这个主题，而是以“你如何提问”的方式，是 37 Signals 博客上的这篇文章 - link text

即使您必须有另一种形式来询问用户可见的问题，而这只会将大部分数据提供给错误程序，我也会这样做只是为了提出正确的问题。

什么产品？什么版本（图片显示如何找到它）？包含屏幕转储会很有帮助，如果他们可以打开程序并按下按钮以自动发送日志文件，是否阻止他们进行进一步的工作，是否丢失了更改等。

对于用户而言，可能更多的是关于您如何提出问题，并让他们知道您需要回答某些问题，或者您会发现哪些问题更有帮助，那么您可能会得到更好的回答。

Answer 5

我同意 Jon Limjap 的观点 - 如果接受了正确的基本培训和指导，您的 QA 人员必须有足够的能力发布适当的错误报告。尽管如此，还是有一些方法可以强制执行和鼓励更好的错误报告：

• 大多数错误跟踪软件都有将错误报告的某些字段标记为必填项的方法，因此报告者必须实际选择适当的值才能成功创建错误
• 通常可以包含错误报告的基本模板，类似于

场景：

预期结果：

实际结果：

备注：

• 您可以（并且应该）提供一个错误报告工具，该工具将在有问题的机器上运行，收集相关信息并将其打包到一个存档文件中（也可以将它放在桌面上）。然后，您指示您的员工在遇到他们希望报告的错误并将存档附加到错误时运行它。该工具应该易于使用（只需运行可执行文件），以便他们将诊断信息附加到任何错误，而不必考虑它是否相关。此工具通常对客户也非常有用。
• 最后但并非最不重要的 - “教育，教育，教育”。人们从经验中学到了最好的东西——只要确保当有人打开一个没有包含正确信息的错误时，处理错误的人会去和打开错误的人交谈，并解释缺少什么以及为什么它很重要。

这些是我们在我目前的工作场所非常成功地使用的做法，我相信它们非常普遍，适合大多数工作环境。

Answer 6

这取决于您是在谈论封闭式 QA 审核还是公开测试版。

如果是公开测试版，不建议让用户直接编辑您的错误列表。应该指派一个人来汇总用户 cmets 和报告，并辨别哪些是实际的错误，哪些是重复的，以及哪些提供一些关于如何复制它们的线索。

但是，如果这是由您的合法 QA 人员发布的错误项目，则您的员工存在能力问题。必须就如何报告错误制定适当的指导方针，尤其是在直接进行复制步骤方面。