Project management 缺陷跟踪最佳实践

在我的公司，以下规则适用：

• 只有测试人员才能创建问题
• 开发人员必须向测试人员发送电子邮件，让他们创建问题
• 开发人员向技术负责人发送电子邮件，让他为他们认为可以解决的问题分配一个问题给他们自己
• 开发人员不能将问题分配给其他开发人员（必须向技术负责人发送电子邮件）
• 如果一个开发人员的问题被另一个开发人员的代码阻止，她必须在bug跟踪系统之外解决这个问题
• 只有测试人员才能关闭自己打开的问题
• 所有作业都必须经过技术主管，以便他能够跟踪问题
• 与用户界面无直接关系的错误不会输入系统（必须从外部解决）

您使用的bug跟踪流程是什么？它对你有用吗？

等等，你写：

如果开发人员的问题被 另一个开发人员的代码，她必须 在bug之外解决这个问题 跟踪系统

因此，有一些bug不属于正常的bug流。然后，您就有了第二个系统来跟踪这些bug，还是这些都是临时的

听起来您的bug跟踪系统实际上是一个用户缺陷跟踪系统

---

它是否适合您，或者您正在寻找替代方案？

我们使用BugZilla进行错误跟踪，有如下规则：

• 任何人都可以报告一个bug，任何微小的变化都应该通过bug跟踪系统。如果是产品中的增强功能，则应将缺陷标记为增强功能，并遵循缺陷跟踪系统

• 任何人都可以将一个bug分配给任何其他人，这意味着如果某个bug驻留在其他人的代码中，则可以轻松地将问题传递给其他人。在某些情况下，可能需要在多个地方修复bug，即首先需要依赖其他人的代码进行修复，然后其他人将修复其代码。在这些情况下，一个bug会被分配给需要首先完成工作的人，然后他/她会通过重新分配它将bug重新路由到合适的人

• 如果一个问题出现在多个地方，并且后面的代码不同，但问题显然是相同的，则会克隆该错误，以便对所有更改保持单独的跟踪

• 技术负责人负责根据特定修复的需求对bug进行优先级排序

• 测试人员/QAE负责为缺陷分配严重性，即严重/主要/次要等

• 所有的bug都要经过bug跟踪系统。来自客户的bug通过自定义标志单独分类，以指示客户bug。客户bug主要存在于较旧的发布版本中，并且为其创建了补丁，因此，这些补丁是分开保存的

---

通过这种方式，我们可以确保同时跟踪源代码管理系统（即TFS btw）和Bugzilla中的所有更改，以便在将来需要时，任何更改都可以追溯到原始代码更改/所有者。

我认为客户也应该能够制造问题，在bug报告和功能请求之间没有分离

问题的分配不应由开发人员自己执行：决定哪些问题必须在下一版本中修复应由客户和经理负责

---

乔尔·斯波尔斯基（Joel Spolsky）还提供了其他练习。

听起来相当复杂。我们大致采用以下流程：

• 公司里的每个人都可以打开一张发行单并将其分配给一个部门
• 每个部门都有一名“调度员”，负责检查收到的票据的有效性并确定其优先级
• 根据部门的实践，调度员为开发人员分配当前开发周期的票证，或者他们为自己分配票证，优先级最高
• 当一张罚单被解决后，它将返回给打开它的人。此人还执行所有必要的活动，如通知客户
• 所有票证都保存在一个软件系统中，使这些任务变得简单。如果你得到一张票，你也会收到一封电子邮件通知

这是一个轻量级的过程，鼓励开发人员为他们的问题负责

除此之外，我们有几个质量保证措施，用于更改软件中的任何内容，无论更改请求的来源和类型如何。这尤其包括：

• 在将所有代码签入源代码管理系统之前，必须对其进行审查。这包括GUI和数据库审查，必要时由专业审查人员进行审查
• 代码在签入之前必须由开发人员自己进行彻底测试
• 在每月构建之后，必须再次测试所有更改，以防止由于影响同一代码的多个更改而出现问题
• 每月的构建进入“第一个客户阶段”，在该阶段，它只在少数客户系统中推出。如果此阶段没有显示以前未检测到的错误，则声明生成是安全的

---

在过去10年中，我使用了几种不同类型的错误跟踪系统，包括nothing、word文档、FogBugz、Bugzilla和Remedy。FogBugz是目前为止最好的一个。在这项工作中，任何人都可以输入bug，任何人都可以将bug分配给其他人。我发现这很有效，尤其是当我在代码中发现一个小错误时。我不用花一个小时写电子邮件、填写表格，也不用让其他人参与，我可以很快地记录我发现并修复了一个bug。这鼓励我输入我发现的所有bug并快速修复它们。如果一个bug需要大量的工作，那么我会把它分配给我的经理，这样他就可以把它与我的其他工作放在一起优先考虑。