您如何强制或维护错误跟踪器中错误报告的质量？

Question

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

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

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

Answer 1

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

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

设想：

预期成绩：

实际结果：

评论：

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

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

Answer 2

我曾经认为错误报告的质量就等同于问题。我还是这么认为...我报告的错误比质量检查或运营输入的错误包含更多有用的信息。然而，我开始欣赏 FogBugz 的模型。输入bug极其简单。即使没有很多支持信息，仅仅知道存在错误情况也是有帮助的。另外，用户感觉事情正在完成。

Answer 3

编写一个关于使用跟踪器以及每个字段所需内容的良好但不太冗长的教程。制作一个通用参考示例，供其他人遇到困难时可以使用。

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

Answer 4

这取决于您谈论的是封闭式质量检查审查还是公开测试版。

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

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

Answer 5

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

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

但在某种程度上，这取决于个人，他们必须意识到这是沟通标准的一部分，这是工作要求，并且他们对团队中的每个其他成员负责 - 因为其他人不应该这样做如果可以避免的话，就无法追捕他们以找出更多细节。

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

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

37 Signals 博客上的这篇文章并不完全涉及这个主题，而是以一种“如何提问”的方式 - 链接文本

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

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

对于用户来说，可能更多的是你如何提出问题，并让他们知道你需要回答某些问题，或者你认为哪些问题更有帮助，然后你可能会得到更好的答复。

Answer 6

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