高质量的错误报告对于在理想环境中进行有效的错误跟踪至关重要，所有错误报告都将包含必要的信息，例如它会影响哪个版本的软件以及有关如何重现该错误的分步说明。

但是，实际上，报告的错误的质量可能相差很大。它们可能是线性的("功能X无效，请修复！")，功能请求，PEBKAC或者难以理解。

我们如何在错误跟踪器中实施或者维护错误报告的质量，以保持有效？

解决方案

回答

这取决于我们是在讨论封闭式质量检查审核还是公开Beta版。

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

但是，如果这是合法质量检查人员发布的错误项目，则员工存在能力问题。必须设置有关如何报告错误的正确准则，尤其是在直接完成复制步骤方面。

回答

我同意乔恩·林贾普(Jon Limjap)的话，质量检查人员必须具备足够的能力，可以发布适当的基本培训和指南，以发布适当的错误报告。尽管如此，仍有一些方法可以强制和鼓励更好的错误报告：

• 大多数错误跟踪软件都有一种将错误报告的某些字段标记为强制性的方法，因此，报告程序必须实际选择适当的值才能成功创建错误。
• 通常可以为错误报告包括一个基本模板，如下所示：

Scenario:
  
  Expected Results:
  
  Actual Results:
  
  Remarks:

• 我们可以(并且应该)提供一个将在有问题的计算机上运行的错误报告工具，收集相关信息并将其打包到存档文件中(也许将其放置在桌面上)。然后，我们指示工作人员在遇到要报告的错误时运行它，并将存档添加到该错误。该工具应该易于使用(仅运行可执行文件)，以便他们可以将诊断信息添加到任何错误，而不必考虑它是否相关。该工具通常对客户也非常有用。
• 最后但并非最不重要的-"教育，教育，教育"。人们可以从经验中学习到最好的东西-只要确保每当有人打开一个没有包含适当信息的错误时，处理该错误的人就会与打开该错误的人进行交谈，并说明缺失的内容以及为什么重要。

这些是我们在当前的工作场所中一直非常成功地使用的实践，我相信它们对于大多数工作环境都是通用的。

回答

棘手的问题。我会尝试查看系统是否可以强制执行我们需要输入的某些字段，并尝试以某种方式(无论是电子邮件还是rss)都遇到了至关重要的错误，以便我们可以快速弹起，但多数情况下团队知道质量标准并遵守它，准则已经发布并公开。

假设是团队：
如果我们可以在注释字段中使用每次输入时预期的某种结构，那么，如果软件具有默认注释大纲，我们可以在其中定义该结构，那就更好了。空白表格。

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

特别是由于修复优先级较低的项目上的错误的周转时间可能会花费一些时间，并且人们一定会在细节上健忘。

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

并非完全围绕这个主题，而是以"我们如何提出问题"的一种方式，这是37 Signals博客链接文本上的帖子

即使我们必须使用另一种形式询问用户可见的问题，即只将大部分数据提供给Bug程序，我也只想提出正确的问题。

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

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

回答

编写一个很好的但不太冗长的教程，介绍如何使用跟踪器以及每个字段的要求。制作一个通用参考示例，以防他人陷入困境。

我有一个用于编辑Docbook手册页的参考副本，通过反复使用它，我已经非常了解大多数语法。

回答

我曾经认为错误报告的质量无异。我仍然这么认为...我报告的错误所包含的信息比QA或者Operations所输入的错误要有用得多。但是，我来欣赏FogBugz的模型。输入错误非常简单。即使没有很多支持信息，仅知道存在错误情况也是有帮助的。另外，用户感觉有些事情要完成了。

回答

最终用户可以使用UserVoice之类的工具来报告错误和功能请求。错误跟踪器条目实际上应该是内部的，对于最终用户而言，它们太技术化，而且恕我直言，它们暴露了太多的内部工作原理。