缺陷跟踪的最佳实践

Question

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

• 只有测试人员可以创建问题。
• 开发人员必须通过电子邮件向测试人员发送请求来创建问题。
• 对于他们认为自己能够解决的问题，开发人员将电子邮件发送给技术主管，请求由技术主管将问题分配给自己。
• 开发人员不能将问题分配给另一个开发人员（必须发送电子邮件给技术主管）。
• 如果开发人员的问题被其他开发人员的代码阻塞，则她必须在错误跟踪系统之外解决此问题。
• 只有测试人员可以关闭由自己打开的问题。
• 所有任务都必须经过技术主管处理，以便他能够跟踪问题。
• 与用户界面无直接关系的漏洞不会输入到系统中（必须通过外部解决）。

你们使用什么错误跟踪流程？它对你们起作用吗？

- buyutec

Answer 1

- Dave

Answer 2

我们使用BugZilla进行bug跟踪，有如下规则:

• 任何人都可以报告bug，所有的微小改变都应该通过bug跟踪系统进行。如果是产品的增强功能，则应将bug标记为增强，并遵循bug跟踪系统。

• 任何人都可以将bug分配给其他人，这意味着如果bug存在于其他人的代码中，则可以轻松地将问题路由到其他人那里。可能会出现一种情况，即需要在多个位置修复bug，即需要先修复其他人的代码才能修复bug，然后再将bug分配给第一个需要执行工作的人，并通过重新分配将其转发给适当的人员。

• 如果问题出现在多个位置且背后的代码不同但问题显然相同，则克隆bug以便可以保留所有更改的单独追踪。

• 技术主管负责根据该特定修复的要求对bug进行优先排序。

• 测试员/QAE负责为bug分配严重性级别，例如：Critical/Major/Minor等。

• 所有bug都经过bug跟踪系统，来自客户的bug通过自定义标志分类以指示客户bug，客户bug大多数在旧版本中发布，因此将它们保持分离。

这样我们就可以确保同时在源代码控制系统（顺便说一下，我们的源代码控制系统是TFS）和Bugzilla中跟踪所有更改，以便将来需要时可以追溯到原始代码更改/所有者。

- Aamir

---

对我来说看起来很理想。请问您能否说明一下管理层如何跟踪谁做了什么，如何确保每个人都有责任心地工作，而不是仅仅将任务分配给其他开发人员，避免责任，然后说“不是我的问题”？ - Serhat Ozgel

团队领导需要跟踪团队内发生的所有事情。因此，如果有任何错误分配，都能够迅速发现。BugZilla拥有一些非常好的搜索机制，可以帮助您跟踪大部分事情，例如谁在做什么，重新打开了多少个错误等。 - Aamir

+1 看起来符合我们的做法。 - Klelky

Bugzilla 安装起来真是太麻烦了！真是太可怕了。 - Vidar

Answer 3

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

• 公司中的每个人都可以打开问题工单并将其分配给某个部门。
• 每个部门都有一个“调度员”负责检查收到的工单是否有效并对其进行优先排序。
• 根据部门的实践，开发人员通过调度员分配当前开发周期的工单，或者自行分配工单（最高优先级）。
• 当工单解决后，它就会返回给开启该工单的人。该人还需要执行所有后续必要的活动，例如通知客户。
• 所有工单都存储在一个软件系统中，使这些任务变得容易。如果您收到一个工单，则还会收到电子邮件通知。

这是一个轻量级的过程，鼓励开发人员对其问题负责。

除此之外，无论更改请求的来源和类型如何，我们都采取了一些质量保证措施来更改软件的过程。尤其包括：

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

- Sebastian Dietz

---

我们使用几乎相同的过程，它运行良好。 - Naveen

Answer 4

我使用过很多问题追踪系统，包括gnats（呕吐！），Bugzilla（稍微好一点），Trac，Jira和现在的FogBugz。 我最喜欢Trac，但这可能是因为我不是FogBugz上的管理员，而且它在当前版本中被悲惨地滥用。

正确地设置工作流程非常重要，有趣的是它始于决定将什么放入您的缺陷跟踪器以及如何标记放入其中的内容。 一旦您有了客户，所有开发团队都会跟踪三种问题：

1. 由实际客户指出的问题（真正的错误）。

2. 当前正在开发的新软件的问题（开发中的错误）。

3. 我们希望在未来做的事情（功能）。

当然，这三类问题每个都有自己的优先级。 “真正的错误”只是一个按钮的拼写错误可能比阻止公开发布或其他开发、测试等方面的“开发中的错误”更加不重要。

问题的严重程度描述了副作用有多可怕。 根据我的经验，这可以归纳为：

1. 程序正在破坏某些东西。数据，客户被错误计费，分配错误的药品。这是最严重的。我曾经在一个系统上工作，其中一个软件命令通过维修人员的中心收回了液压臂。这是最严重的。

2. 程序正在崩溃，我们没有解决方法，但在此期间它不会破坏任何东西（除了宕机）。如果停机导致某些东西被破坏，请使用严重性#1。

3. 程序正在发生错误，但我们已经找到了可以实际使用的解决方法。

4. 程序以影响结果的方式出现问题，但并不影响结果。

5. 程序需要在某些明确定义的方面变得更好：更易于使用，实现新功能，运行更快等。

这些系统中经常出现的另一个问题是“角色”的概念。 在应用于问题追踪系统时，“角色”归结为谁被允许做什么。 谁有权创建问题？ 谁有权更改状态，谁有权将其重新分配给其他用户，谁有权关闭它们等。

在我密切合作过的小型到中型团队中，这些通用规则已经运作良好：

• 任何人都可以创建问题。创建者在创建过程中可以将问题分配给任何（或大多数）收件人。默认收件人是问题分类小组。开发人员可以通过这种方式记录他们在代码上工作时发现的错误，并将错误分配给自己，以跟踪他们更改代码的原因。

• 问题分类小组定期会面（指定间隔时间）以评估和分配问题。问题分类小组专门寻找重复报告，在这种情况下，新问题将“合并”到现有问题链中；对于无法从现场复制的问题，它们将被分配给QA进行复制；以及来自客户的严重问题。

• 缺陷的发起者是唯一可以关闭它的人。QA或CSR发起的错误报告不能由开发人员关闭。是的，这意味着CS和开发团队意见不一致的错误仍未解决。如果您想要一个数字谎言库，那就看C-SPAN吧，为什么让问题跟踪器报告问题已解决？

一些团队可能希望保留将问题从一个部门移动到另一个部门的权利，而其他团队则允许任何团队成员将问题移到（或返回）另一个团队。这可能归结为管理怀疑，或者仅仅是谁被允许分配工作时间。

问题分类过程是关键。问题分类小组实际上就是您的组织中决定谁做什么、下一步做什么的人。定期安排会议有助于确保不会漏掉真正重要的事情，并且由于注意力不足而失去了平凡的东西。如果问题分类队列中没有任何内容，则会议（电话会议、网络会议或其他实现方式）可以由主持人取消。

如果使用Scrum，则问题分类小组可能是Scrum Master，决定是否将问题拉入当前Sprint并适当分配优先级，如果将其放入待办事项列表。

- Wes Peters

---

2和3之间的优先级似乎有些问题。如果程序没有崩溃，但表现不正常，并且没有解决方法怎么办？也许应该将3和4交换位置。 - Andreas Haferburg

Answer 5

记录bug的重点在于速度-只需要最少量的信息来调查/复制这个bug。

对于网站项目，有三个关键因素：1）一个描述性的bug标题，2）错误发生的页面，3）问题的描述+截图OR逐步说明如何复制问题（如果没有提供截图）。

截图非常有用，有两个原因：1）图片胜过千言万语，2）它为bug报告提供了可信度（您是否曾经调查过无法复制的bug，并想“看起来客户又在编故事了”？）

我有一篇关于这个主题的博客文章：Logging Bugs Like a Pro。

- louism

Answer 6

等一下，你写道：

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

因此，有些错误不属于正常的错误流程。那么你是否有第二个系统来跟踪这些错误，或者这些都是临时处理的？

听起来你的错误跟踪系统实际上是一个用户缺陷跟踪系统。

它对你来说工作得很好吗，还是你正在寻找替代方案？

- Christopher Mahan

---

我认为它对于管理工作非常有效（当然不适用于我，但这是我无法改变的事情）。你提到的第二个系统主要是电子邮件。 - Serhat Ozgel

当员工们应该关注的东西完全不可见时，它对管理工作如何有帮助呢？ - David Thornley

Answer 7

我认为客户也应该能够创建问题，没有将错误报告和功能请求分开。

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

Joel Spolsky在他的 Painless Bug Tracking 中提出了其他实践方法。

- mouviciel

---

如果一个分配给我的问题需要另一个开发人员的工作怎么办？我不应该将它分配给她吗？ - Serhat Ozgel

在我看来，这是经理角色将工作分配给开发人员。我认为，如果经理将问题分配给您，要么您能够成功，要么他不了解自己的团队，在这种情况下，与他进行讨论可能会解决问题。 - mouviciel

这意味着经理需要分配所有任务，而且是单点故障。如果团队能够定期处理事务，并在适当时经理介入，那不是更好吗？ - David Thornley

是的，你说得对。我意识到过于严格的政策可能会导致微观管理。无论如何，经理在问题分配和其他任务方面都有一定的作用，并且本质上是单点故障。 - mouviciel

Answer 8

在过去的十年中，我使用过几种不同类型的缺陷跟踪系统，包括没有系统、Word文档、FogBugz、Bugzilla和Remedy。其中，FogBugz是最好的一个。在那份工作中，任何人都可以输入缺陷，也可以将其分配给其他人。我发现这样做很有效，特别是当我在代码中发现了一个小bug时。我可以快速记录我找到并修复了这个问题，而不必花费一小时写电子邮件、填表格并让其他几个人参与进来。这鼓励我录入所有我发现的缺陷并快速修复它们。如果一个缺陷需要大量工作，则我会将其分配给我的经理，以便他可以将其与我的其他工作进行优先排序。
在使用Bugzilla的工作中，每当创建、分配或更改缺陷时，所有开发人员和经理都会收到一封电子邮件。这产生了相反的效果，它使我不愿意在系统中查找和输入缺陷。

- Rossini

---

这是因为设置系统的人没有足够地精细划分电子邮件。这实际上并不是Bugzilla的错。 - Christopher Mahan

Answer 9

我的小店使用了一个相当简单的工作流程：

• 任何人都可以创建问题（我认为不允许这样做是不必要的限制）。这包括我们开源项目的客户和用户。
• 变更控制委员会（听起来很高大上，但实际上只有QA负责人、工程主管和产品经理）审查新问题并分配修复版本和优先级。
• 任何人都可以重新分配错误，向报告人提问或将其传递给另一个人进行修复或测试。
• 任何人都可以标记错误已解决。
• 只有QA才能关闭错误——我们这样做是为了强制执行每个错误修复的验证。

这样，所有事情都被记录在错误跟踪系统中，并且通过不限制更新来保持效率。这样可能会导致一些“错误垃圾邮件”，但根据我的经验，这比创建瓶颈要好。

我们使用JIRA作为我们的错误跟踪器——在JIRA中可以设置各种自定义工作流程以强制执行您的特定过程，但在较小的组织中，我从未发现有必要这样做。

- gareth_bowles

Answer 10

你在使用哪种缺陷跟踪流程？

• 测试人员将发布所有处于打开状态的错误
• 分配给开发人员
• 开发人员将尝试修复错误 - 已修复
• 错误已关闭
• 重新打开错误状态

- Ricky Ponting