高质量的错误报告对于有效的错误跟踪至关重要 - 在理想情况下，所有错误报告都将包含基本信息，例如它影响的软件版本以及如何重现错误的分步描述。
但实际上，报告的错误质量可能有很大差异。他们可能是在线的（“功能 X 不起作用，修复它！”）、功能请求、PEBKAC 或无法理解。
您如何执行或维护错误跟踪器中错误报告的质量以保持有效性？
vetler
问问题
531 次
6 回答
3
我同意 Jon Limjap 的观点——你的 QA 人员必须有足够的能力发布适当的错误报告，前提是得到正确的基本培训和指导。尽管如此，还是有一些方法可以强制执行和鼓励更好的错误报告：
- 大多数错误跟踪软件都有将错误报告的某些字段标记为必填项的方法，因此报告者必须实际选择适当的值才能成功创建错误
- 通常有可能包含错误报告的基本模板，类似于以下内容
设想：
预期成绩：
实际结果：
评论：
- 您可以（并且应该）提供一个错误报告工具，该工具将在有问题的机器上运行，收集相关信息并将其打包到存档文件中（并可能将其放在桌面上）。然后，您指示您的员工在遇到他们希望报告的错误并将存档附加到错误时运行它。该工具应该易于使用（只需运行可执行文件），以便他们将诊断信息附加到任何错误，而不必考虑它是否相关。该工具通常对客户也非常有用。
- 最后但并非最不重要的 - “教育，教育，教育”。人们从经验中学到了最好的东西——只要确保当有人打开一个没有包含正确信息的错误时，处理错误的人会去和打开错误的人交谈，并解释缺少什么以及为什么它很重要。
这些是我们在我目前的工作场所非常成功地使用的做法，我相信它们非常普遍，适合大多数工作环境。
于 2008-08-30T11:11:38.507 回答
3
我曾经认为错误报告的质量无异。我仍然这么认为……我报告的错误比 QA 或操作输入的错误包含更多有用的信息。然而，我开始欣赏 FogBugz 的模型。输入错误非常简单。即使没有很多支持信息，只要知道存在错误情况就会很有帮助。此外，用户感觉某事正在完成。
于 2008-08-30T13:24:05.833 回答
1
写一个关于使用跟踪器以及每个字段需要什么的好但不太长的教程。制作一个通用参考示例，其他人在遇到困难时可以使用。
我有一个用于编辑 Docbook 手册页的参考副本，通过反复使用，我已经牢记大部分语法。
于 2008-08-30T11:17:03.457 回答
0
这取决于您是在谈论封闭式 QA 审查还是公开测试版。
如果它是公开测试版，不建议让用户直接编辑您的错误列表。应该指派一个人来汇总用户评论和报告，并辨别哪些是实际的错误，哪些是重复的，哪些提供了一些关于如何复制它们的线索。
但是，如果这是由您的合法 QA 人员发布的错误项目，则您的员工存在能力问题。必须就如何报告错误设置适当的指导方针，尤其是在直接进行复制步骤时。
于 2008-08-30T10:51:00.087 回答
0
棘手的问题。我会尝试看看系统是否有任何方法可以强制输入您需要的某些字段，尝试以某种方式（电子邮件，rss）让任何重要的错误出现在您的眼前，这样您就可以快速突袭，但主要是您的团队了解质量标准并遵守它，指南已发布并公开，诸如此类。
假设它是您的团队：如果您可以在评论字段中每次都使用某种结构，输入时的预期内容，那么这也很好 - 如果您的软件有一个默认的注释大纲，您会更好可以在空白表格上定义该结构。
但在某种程度上，这取决于个人，他们必须意识到这是沟通标准的一部分，这是预期的工作要求，并且他们对团队的每个其他成员负责——因为其他人应该如果可以避免的话，我无法追捕他们以找出任何进一步的细节。
特别是因为修复较低优先级项目的错误的周转时间可能需要一些时间，而且人们肯定会忘记细节。
假设它是用户：你不能达到很高的程度，但我会尝试 - 如果可能的话，以人们可以理解的方式提出任何形式的问题。
不完全是关于这个话题，而是以“你如何提问”的方式，是 37 Signals 博客上的这篇文章 -链接文本
即使您必须有另一种形式来询问用户可见的问题，它只会将大部分数据提供给错误程序，我也会这样做只是为了提出正确的问题。
什么产品？什么版本（图片显示如何找到它）？包含屏幕转储会很有帮助，如果他们可以打开程序并按下按钮以自动发送日志文件，它是否阻止他们做进一步的工作，是否丢失了他们的更改等。
对于用户来说，可能更多的是关于您如何提出问题，并让他们知道您需要回答某些问题，或者您会发现哪些问题更有帮助，那么您可能会得到更好的回答。
于 2008-08-30T11:15:11.383 回答
0
使用诸如UserVoice之类的东西供最终用户报告错误和功能请求。错误跟踪器条目确实应该是内部的——它们对最终用户来说太技术性了，而且，恕我直言，暴露了太多的内部工作。
于 2009-05-07T02:32:08.107 回答