团队中关于 Bug 报告的一些思考

这是一个令人沮丧的情况：有人注意到一个真实的布局错误或某种故障，但他们在告诉你时未能准确描述问题。 作为前端开发人员，以及全面的优秀团队成员，我们有责任建立一个工作流程来报告、编目和描述人们可能遇到的错误。

在团队环境中建立一个 Bug 报告系统有很多好处

• 了解当前存在的 Bug。
• 了解谁在做什么（以及他们需要什么）。
• 概述完成工作需要多长时间。
• 查找被阻塞的任务或那些在解决之前需要某种依赖关系的任务。

第一步是选择一个每个人都觉得舒适的工具

有了可靠的 Bug 修复系统，我们就能更好地完成优秀的工作，但需要注意的是，良好的 Bug 报告技能不仅仅是开发人员的要求。 团队中的每个人都应该能够找到 Bug 并提供尽可能多的相关信息。 这意味着所有经验水平的设计师、开发人员和项目经理都不应该害怕使用 Bug 工具并全面了解项目。

我一直发现 Trello 是我个人最喜欢的，因为它对团队的其他成员更有意义，但这并不一定意味着它最适合您的特定用例。 以下是一些值得关注的最受欢迎的 Bug 跟踪工具和服务

• Trello
• Stack
• Sifter
• Waffle
• Basecamp
• JIRA
• GitHub Issues
• Asana
• BugHerd

无论我们选择什么工具，最终我们需要确保每个人都对建议的工作流程感到满意，因为我们需要每个人的帮助来记录、整理和搜索项目中潜在的 Bug。

无帮助的 Bug 报告

即使您选择了完美的工具，也并不一定意味着每个人都会以有帮助的方式使用它。 我遇到过很多次因为缺乏信息而难以找到报告的 Bug 的情况。

不太有帮助

• “IE 中列表样式坏了”
• “在页面上滚动时出现奇怪的故障”

事实上，这些类型的评论对开发人员来说几乎毫无用处，因为它们不够 *具体*。 开发人员更希望 Bug 报告包含诸如 *谁、什么、哪里、何时以及为什么* 等信息。

有帮助的 Bug 报告

虽然这完全取决于手头的特定情况，但最好阅读类似以下内容的信息

“联系页面上的特殊列表样式在 Firefox 和 IE11 中错误地定位在其容器的左侧。 请参阅附图了解更多信息。”

从这里，开发人员可以立即找到有问题的 Bug 并开始为该问题设计合适的解决方案。

但是，我们如何帮助团队中的其他人编写 *优秀的* Bug 报告呢？

我发现，在项目开始时与团队中的每个人坐下来详细概述我们应该如何与他们合作非常有帮助。 谁来决定 Bug 何时修复？ 谁来审查哪些特定的代码部分？ 我们应该使用哪些自动化工具来查找 Bug？ 当设计团队也发现 Bug 时，我们需要哪些资产？ 这些都是重要的问题，如果得不到解答，可能会导致令人沮丧的问题。

我列出了我对大多数 Bug 报告的期望

1. 简洁明了（但不要粗鲁）

理想情况下，我们希望使用项目符号而不是长句子，以便开发人员能够尽快找到问题，但这并不意味着我们可以简短粗暴。 最好尽可能准确地描述问题，并尽量减少阻碍。 如果有人构建了该特定功能并了解其来龙去脉，也许您应该首先将其分配给他们。 但是，不要把所有的责任都推卸给他们。

2. 务必添加屏幕截图和/或 GIF

特别是对于动画和复杂的交互 Bug，动画 GIF 几乎是突出显示缺陷特性的必备条件。 然而，在大多数情况下，简单的屏幕截图将帮助我们找到可以在其中找到 Bug 的视图或模板。

动画 GIF 抓取工具

• GifGrabber
• PicGIF
• LICEcap

（屏幕截图/GIF/视频）+ 云存储工具

• Droplr
• CloudApp
• Screenr

并且不要忘记在 GitHub Issues 中，您可以直接拖放屏幕截图

3. 识别浏览器版本

如果您只是引用浏览器名称（如“Chrome”或“IE”）并没有什么帮助，如果您提供特定的浏览器版本（如“Chrome 42”或“IE8”）会更好。 但是，如果您还能确定该 Bug 在其他浏览器中是否不存在，那就更好了，例如：“我在 iOS 8.3 中发现了此 Bug，但在任何其他 Webkit 浏览器中都无法重现。” 通过此类信息，您可以为开发人员节省大量时间，并且他们可以更快地识别问题所在。

如果您想确保发送所有可能的信息，可以使用像 Support Details 这样的工具，它可以获取很多信息并允许您通过电子邮件发送或将其转换为 PDF（或仅截屏以包含）。 如果您有自己的 Bug 报告控制，您甚至可以抓取并预填充隐藏字段以获取此信息，这样您无需报告者任何操作即可获取。

4. 记录 Bug 可以在哪个模板、视图或页面上找到

如果它在 /blog 或 /contact-us 页面上，或者如果它可以在特定的部分（例如页眉或页脚）中找到，请尽快让开发人员知道。

完整的 URL 通常非常有用。

5. 不要忘记提及可能导致问题的特定模块或类

如果您更熟悉前端并想为开发人员提供问题的答案，您需要做两件事：首先，您需要从团队中的每个开发人员那里获得一个击掌，因为在报告 Bug 的同时告诉开发人员如何修复它是一件大事。 但其次，您可能需要创建一个 简化测试用例。 这涉及将代码分解成小块并逐一剔除，直到您揭示了确切发生的情况。 通过这些信息，您将专注于有问题的代码部分，并让每个人的生活都变得轻松一些。

6. 查看是否存在任何控制台错误或通知

与其复制/粘贴控制台错误，如果存在任何警告，最好截取屏幕截图。它们可能与您发现的特定错误无关，但可能正是导致一切混乱的原因。

7. 再次确认错误是否已被其他人发现

在我参与的项目中，重复提交错误报告通常不是什么大问题，但如果存在大量问题，肯定值得快速浏览已归档的错误或当前打开的问题，看看是否可以找到您的错误。

此任务可能还涉及您浏览并查看哪些错误相似，以及在您使用的应用程序中标记问题。如果错误确实已被发现，那么也许值得添加更多信息或在卡片上注明您在哪里发现了同一问题的新的实例。

8. 将任务分组到特定的类别中

我发现，在 Trello 中使用标签功能将问题标记为“受阻”特别有用。一个醒目的红色标签会让每个人都知道与该任务相关的另一个问题必须首先解决。

类似地，将每个人的任务分成特定的领域也很有帮助，例如：

• 内容
• 设计
• 前端
• 集成/后端
• 错误
• 代码审查
• 已完成

这让我们能够概览项目时间线，并让开发人员有机会一览所有错误。

大多数错误报告软件都具有分类功能。例如标签、分类、标记、分配等等。

9. 记录您现有的错误任务工作流程

如果您觉得已经建立了良好的工作流程，那么也许您应该创建一个包含流程细节的文档。这不仅对您自己的组织有用，也可能帮助其他人避免犯同样的错误。这里有两个参考：Thoughtbot playbook 和 Harry Roberts 关于其 Trello 工作流程的文章

总结

我一直认为错误列表不应该是令人望而生畏、令人不堪重负的压力，它不应该让团队中的每个人都渴望争吵和争执。相反，错误列表应该激励我们撸起袖子，鼓励我们尽我们所能提供帮助。因此，如果我们花一点时间来弄清楚流程中的这些小细节，也许我们就能摆脱所有这些负担，并继续为网络构建伟大的事物。

您的错误审查流程是什么样的？您发现哪些工具有用？请在下方添加评论，我一定会更新这篇文章以供将来参考。