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

Question

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

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

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

Answer 1

我同意Jon Limjap - 鉴于正确的基本培训和指导方针，您的QA人员必须有足够的能力发布适当的错误报告。然而，有一些方法可以强制执行并鼓励更好的错误报告：

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

  

情景：

     

预期结果：

     

实际结果：

     

说明：

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

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

Answer 2

我曾经认为错误报告的质量无异于此。我仍然这么认为......我报告的错误中包含的错误比QA或Operations输入的错误要多得多。但是，我来到这里欣赏FogBugz的模特。输入错误非常简单。即使没有很多支持信息，只要知道有错误条件也是有帮助的。此外，用户感觉有些事情已经完成。

Answer 3

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

我有一个用于编辑Docbook手册页的参考副本，并且通过反复使用我已经了解了大部分语法。

Answer 4

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

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

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

Answer 5

棘手的问题。我试着看看系统是否有任何方法可以强制执行你需要输入的某些字段，尝试并以某种方式（电子邮件，rss）让你的眼睛有任何重要的错误，这样你就可以迅速突袭，但主要是你的团队意识到质量标准并坚持下去，指导方针是公开的，公开的，等等。

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

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

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

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

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

即使您必须有另一个表单询问用户可以看到的问题，这些问题主要是将数据提供给错误程序，我只是提出正确的问题。

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

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

Answer 6

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