好的错误报告是质量控制的氧气。把它们拿走，一切都变酸了。作为一名客户支持主管，我花了大量时间与客户进行技术讨论，从API辩论到复杂的SDK边缘案例。我们的最终目标是让顾客满意，但不同的谈话方式会有所不同。有时我只需要解释一些事情，有时我需要编写一些示例代码或调试他们的代码，有时我们需要更新或澄清我们自己的文档，有时我需要提交一个bug来快速修复某些问题。好的bug报告可以简化对产品团队的调查，并让他们快速地进行分类。如果错误再次发生，或者类似的事件发生，一个有良好文档记录的bug报告库可以提供有价值的上下文。好的错误报告的特点

我们使用Github问题来记录我们的bug，但是不管您使用什么服务，建议都是一样的。伟大的头衔一个好的标题可以被你的同事扫描，以立即了解发生了什么，在哪里，何时，如何发生的。记住，这是必须从一系列其他问题中挑选出来的。一个描述性标题也将确保同一个bug的重复报告能够被快速发现。一个不好的例子：对于这个用户来说，用户列表是不完整的为什么？怎么可能有人知道这是什么，而不必点击和阅读更多？一个很好的例子：在osxff34上的Linux中用户列表不可滚动为什么？这有很多细节，包括操作系统和正在使用的浏览器。简明扼要的描述尽可能详细地说明实际发生了什么，以及用户是如何体验的。注意不要把用户对事件的描述当成福音。通常他们只会谈论他们的经历，而不是实际发生的事情。例如，客户可能会说，"消息停止发送"。它真的停止了发送，还是用户界面告诉他们它停止了发送？当我们使用对讲机为对讲机提供支持时，我们总是链接到客户强调问题的相关对话。如何繁殖要重现一个bug，您需要记录它发生的相关条件和触发它的必要步骤。条件包括从浏览器/操作系统/邮件客户端到客户状态（例如付费、新或旧）。确保包括清晰的步骤来重现，即在屏幕上所采取的任何导致破坏状态的操作。给它贴上标签标签也很重要，这样可以优先处理问题。我们用以下标签标记Bug：严重性：我们有问题的标签（p-levels），从"删除所有内容并修复此问题"到"下一次更改流程时将其清理干净"。团队：哪个产品团队受到影响。如果对应该通知哪个团队有疑问，我们会为这两个团队添加标签。这里的关键是确保相关产品经理和工程负责人立即得到提醒（我们向相关团队的Slack频道发送GitHub通知）。客户频率：我们的团队标记每天或每周发生的频繁问题。这些问题对产品来说可能不是关键的（就p-level而言），但它们非常频繁，因此快速修复它符合每个人的利益。原因：我们想确定这个bug为什么会肆虐，并根据原因我们能做些什么来确保它不再发生。有些错误你无法防止，但有些是可以通过适当的测试或质量保证来预防的。这里的示例标记包括可接受的、缺少的自动化测试、错误的设计/开发决策或缺少人工QA。控制台调查我们的客户支持团队有许多工程师，因此在升级之前，我们自然会进行自我调查。像FullStory的Dev Tools这样的工具可以让我们看到控制台日志对于我们站点上的真实访问者来说是什么样子。包括我们调查的控制台输出对于传递上下文非常有用。接收工程师可以根据这个逻辑进行构建，或者判断错误并关闭它——不管怎样，都节省了时间。礼品和截图屏幕截图是UI bug的货币，gif是交互bug的等价物。如果有些东西很刺耳，比如一个粗糙的动画或中断的转换，Gif是最简单的沟通方式。秀，不要说。检查Javascript控制台如果用户界面有问题，最好检查Javascript控制台。我们有一个保存的答复，因为这是一个如此宝贵的信息从我们的用户。对于任何非技术人员来说，这意味着点击--——任何红色都是不好的。同样，冒犯性文本的截图很有价值。其他注意事项每次都会发生这种错误吗？或者是零星的。这将影响缺陷的严重性和调查的复杂性。在这件事发生之前你在做什么？通常情况下，有一个冒犯的先前状态没有被注意到（例如，我是通过点击电子邮件中的这个链接到达这里的）如果错误导致崩溃，崩溃日志是否提供了潜在原因的线索？使用什么插件？有很多，很多，流行但维护不好的插件会给浏览器带来麻烦。错误报告的永恒规则在QA思想中，Rands概述了bug报告的黄金法则。简明扼要地说：如果你发现产品有什么问题，不管大小，都要尽你所能报告。花时间报告问题是一个很好的做法，尽可能详尽地描述问题，但更重要的是报告问题。检查问题是否已被其他人报告也是一种良好的做法，但更重要的是报告该问题。不管多么简陋，坏报告总比没有报告好。公司里的每个人，从首席执行官到暑期实习生，都应该知道，如果他们发现你的产品有问题，该怎么提醒谁。