38. 如何使用Bug跟踪系统

如何使用Bug跟踪系统

        不管你叫他们什么，bug（小错误），defect（缺陷），或者design side effect（设计副作用），总得和他们打交道。知道如何提交一个好的bug report以及在其中查看什么，是保持项目良好进展的关键技能。
        好的bug report需要三点：
        · 如何重现bug，要尽可能精确以及这种场景下bug的出现频率。
        · 期望发生什么，至少要表明你自己的观点。
        · 实际发生了什么，至少要或者尽量多地记录信息。
        bug里面的信息的质量和数量也包含着提交者的信息，和bug的信息一道。愤怒的、简短的bug（“这功能太搓了！”）没有告诉开发人员什么东西，除了你很不爽。提交一个有着足够多上下文内容来更容易地重现的bug会取得别人的尊敬，即使它阻止了一场发布。
        Bug就像是谈话一样，每个人都能看到它所有的历史信息。不要则怪别人，也不要否认bug的存在，而是咨询更多的信息并想想你是不是漏掉了什么。
        更改bug的状态，例如，从开启到关闭，是你对bug的看法的一个公开声明。花点时间解释你为什么觉得bug应该关闭可以省很多事，不用花费数小时的无聊时间去向不明就里的管理人员和客户作辩解。更改bug的优先级也是类似的声明，并不是它对你微不足道就意味着其他人就不会使用产品了。
        不要因自己的目的而过多地标记bug的字段。在bug的标题增加一个“致命的”，也许可以让你自己在报告中排序起来更方便，但是它最终会被复制，于是免不了搞错类型，或者需要移除它以便在其它的报告中使用。使用一个新的值或者字段来代替，并在文档中说明这个字段应该是怎么用的，以便其他人不用做重复工作。
        确保每个人都知道如何查找团队工作中的bug。这经常可以通过使用一个公共的、有着明显意义的名称的查询来实现。确保每个人都使用相同的查询，并且在未通知团队成员的情况下不要更新这个查询，不要改变每个人正在使用的东西。
        最后，记住bug不是一个标准的工作单位，就像一行代码不是努力的精确度量一样。

原文：How to Use a Bug Tracker by Matt Doar