错误跟踪最佳做法

Question

在我的公司，这些规则适用：

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

您使用的是什么错误跟踪流程？它适用于你吗？

Answer 1

Answer 2

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

• 任何人都可以报告错误，每一个小小的改动都应该通过错误跟踪系统。如果它是产品的增强功能，则应将错误标记为增强功能，并应遵循错误跟踪系统。

• 任何人都可以将错误分配给任何其他人，这意味着如果错误存在于其他人的代码中，则可以轻松地将问题路由到其他人。可能存在需要在多个地方修复错误的情况，即，依赖于其他人的代码以首先得到修复，之后其他人将修复他/她的代码。在这些情况下，将错误分配给需要先完成工作的人，然后通过重新分配将错误重新路由到适当的人。

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

  < / LI>

• 技术主管负责根据特定修复程序的需求确定错误的优先级。

• 测试人员/ QAE负责为该错误指定严重程度，即严重/重大/轻微等。

• 所有错误都经过错误跟踪系统。来自客户的错误由自定义标志分别分类，以指示客户错误。客户错误主要在较旧发布的版本中，并且为它们创建了补丁，因此，这些错误是分开的。

这样我们就可以确保在源代码管理系统（TFS btw）和Bugzilla中同时跟踪所有更改，以便任何更改都可以追溯到原始代码更改/所有者（如果需要）将来

Answer 3

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

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

这是一个轻量级的流程，鼓励开发人员为他们的问题承担责任。

除此之外，无论变更请求的来源和类型如何，我们都会为软件中的任何内容更改过程制定多项质量保证措施。这尤其包括：

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

Answer 4

我使用过大量的问题跟踪系统，包括gnats（呃！），Bugzilla（略少ugh），Trac，Jira和现在的FogBugz。我最喜欢Trac，但这可能是因为我不是FogBugz的管理员，而且它目前的化身正在被遗忘和可怕地误用。

正确使用工作流程非常关键，奇怪的是，它首先要确定将什么放入您的错误跟踪器以及如何标记放在那里的内容。只要您有客户，所有开发团队都会真正跟踪三种问题：

1. 真实客户注意到的问题（实时错误）。

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

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

当然，这三类问题中的每一类都有自己的优先事项。一个“实时错误”只是一个按钮上的拼写错误，可能比阻止公开发布的版本或者其他开发，测试等的“开发错误”重要得多。

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

1. 该程序正在破坏某些东西。数据，客户收费不正确，错误的药物被分发。这和它一样糟糕。我曾经在一个系统上工作，软件命令将液压臂缩回到维修人员的中间。这很糟糕。

2. 程序正在崩溃，我们没有解决方法，但在此期间它并没有毁掉任何东西（除了失败）。如果停机时间导致毁坏，请使用严重性＃1。

3. 该程序行为不端，但我们已确定可以实际使用的解决方案。

4. 该计划以令人讨厌的方式行为不端，但不影响结果。

5. 程序需要以一种定义明确的方式更好：更容易使用，实现新功能，运行更快等等。

在这些系统中出现的另一个问题是“角色”的概念。适用于问题跟踪系统，角色归结为允许谁做事。谁来创造问题？谁可以改变状态，谁可以将他们重新分配给另一个用户，谁来关闭他们等等。

在我与之密切合作的中小型团队中，这套一般规则运作良好：

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

• Triage团队会面（指定此处的间隔）以评估和分配问题。 Triage团队专门寻找重复报告，在这种情况下，新问题“卷起”到现有的问题链中;来自实地的未经批准的问题，这些问题被分配给QA进行复制;以及来自客户的高严重性问题。

• 错误的发起者是唯一可以关闭它的人。 QA或CSR发起的错误报告无法由开发人员关闭。是的，这意味着CS和开发团队不同意的错误仍未得到解决。当人们不同意时，为什么问题跟踪器报告问题已解决？如果你想要一个谎言的数字存储库，你有C-SPAN。

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

Triage流程是关键。 Triage团队基本上是您组织中的任何人决定谁在哪些方面工作，以及接下来要做什么。让团队定期举行会议有助于确保不会错过真正重要的事情，并且由于注意力不集中而不会丢失普通的东西。如果Triage队列中没有任何内容，会议负责人可以取消会议（concall，netmeeting，无论实施情况如何）。

如果您正在使用Scrum，那么Triage团队可能就是Scrum主管，决定是否将问题拉入当前sprint并正确分配优先级，如果它进入积压工作。

Answer 5

等等，你写道：

  

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

所以有些错误超出了正常的bug流程。那么你有第二个跟踪这些错误的系统，或者这些都是临时的？

听起来您的错误跟踪系统确实是一个用户缺陷跟踪系统。

它对您有效还是在寻找替代方案？

Answer 6

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

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

其他做法可以在Joel Spolsky的Painless Bug Tracking中找到。

Answer 7

在过去的10年里，我使用了几种不同类型的错误跟踪系统，包括什么，单词文档，FogBugz，Bugzilla和Remedy。 FogBugz是迄今为止最好的一个。在那个工作中，任何人都被允许输入错误，任何人都可以将错误分配给其他任何人。我发现这很有效，特别是如果我在代码中发现了一个小错误。我可以快速记录我找到的并修复了一个错误，而不是花一个小时写电子邮件并填写表格并让其他人参与其中。这鼓励我输入我发现的所有错误并快速修复它们。如果一个bug需要大量的工作，那么我会将它分配给我的经理，这样他就可以将其优先于我的其他工作 在我使用Bugzilla的工作中，每次创建，分配或更改错误时，都会向所有开发人员和经理发送电子邮件。这产生了相反的效果，它阻止我在系统中查找和输入错误。

Answer 8

日志记录错误与速度有关 - 只是调查/复制错误所需的最少信息量

对于Web项目，

归结为：1）描述性错误标题，2）发生错误的页面，3）问题描述+屏幕截图 OR < / strong>复制问题的逐步说明（如果未提供屏幕截图）

截图非常强大有两个原因：1）图片说千言万语，2）它给出了错误报告的可信度（曾经调查过一个你无法复制和思考的错误“看起来客户端正在重新填充内容“？）

我有一篇博客文章进一步讨论了这个主题：Logging Bugs Like a Pro

Answer 9

我的小商店使用非常简单的工作流程：

• 任何人都可以创建一个问题（我认为不允许这样做是不必要的限制）这包括我们的开源项目的客户和用户。
• 变更控制板（听起来很奇特，但它只是QA领导和工程负责人，再加上产品经理）审核新问题并指定修复版本和优先级
• 任何人都可以重新分配错误，向记者提问或传递给其他人进行修复或测试
• 任何人都可以标记已解决的错误
• 只有QA可以关闭错误 - 我们这样做是为了强制验证每个错误修复。

这样，一切都记录在错误跟踪系统中，我们通过不限制更新来保持高效。你可以用这种方式得到一些“垃圾邮件”，但这比我的经验中创造瓶颈要好。

我们使用JIRA作为我们的错误跟踪器 - 可以在JIRA中设置各种自定义工作流程来强制执行您的特定流程，但我从未发现需要在较小的组织中执行此操作。

Answer 10

  

您使用的是什么错误跟踪流程？

• 测试人员会将所有错误发布在开放状态
• 分配给开发人员
• 开发人员将尝试修复错误 - 已修复
• Bug已关闭
• 重新开启错误状态