错误跟踪最佳做法

在我的公司,这些规则适用:

只允许测试人员创建问题.

开发人员必须向测试人员发送电子邮件,让他们创建问题.

开发人员向技术主管发送电子邮件,让他为自己分配问题,以解决他们认为可以解决的问题.

开发人员无法将问题分配给其他开发人员(必须向技术主管发送电子邮件).

如果开发人员的问题被其他开发人员的代码阻止,她必须在错误跟踪系统之外解决此问题.

只允许测试人员关闭自己打开的问题.

所有作业必须通过技术主管才能跟踪问题.

与用户界面无直接关系的错误不会输入系统(必须在外部解析).

你使用什么错误跟踪流程？它适合你吗？

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

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

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

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

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

测试人员/ QAE负责为该错误分配严重性,即严重/重大/次要等.

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

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

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

公司中的每个人都可以打开发票并将其分配给部门.

每个部门都有一名"调度员",他会检查收到的有效票并确定优先顺序.

根据部门的实践,开发人员会为调度员分配当前开发周期的票证,或者他们首先为自己分配票证,优先级最高.

当一张票解决后,它会回到打开它的人身上.此人也会在之后执行所有必要的活动,例如通知客户.

所有票证都保存在软件系统中,使这些任务变得简单.如果您获得了票证,您还会收到电子邮件通知.

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

除此之外,无论变更请求的来源和类型如何,我们都会为软件中的任何内容进行更改,并采取多种质量保证措施.这尤其包括:

在检入源代码管理系统之前,必须检查所有代码.这包括必要时由专业审阅者进行的GUI和数据库审查

在签入之前,开发人员必须彻底测试代码.

每月构建之后,必须再次测试所有更改,以防止由于影响相同代码的多个更改而发生的问题.

每月构建进入"第一个客户阶段",它只会推广到少数客户系统.如果此阶段未显示以前未检测到的错误,则表明构建是安全的.

我已经使用了大量的问题跟踪系统,包括gnats(呃!),Bugzilla(略少ugh),Trac,Jira和现在的FogBugz.我最喜欢Trac,但这可能是因为我不是FogBugz的管理员,而且它在当前的化身中被遗忘和可怕地误用了.

正确地完成工作流程非常重要,奇怪的是,它首先要确定将什么放入您的错误跟踪器以及如何标记您放在那里的东西.只要您有客户,所有开发团队都会真正跟踪三种问题:

真实客户注意到的问题(实时错误).

目前正在开发的新软件存在问题(开发错误).

我们希望将来做的事情(功能).

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

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

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

程序崩溃了,我们没有解决方法,但在此期间它并没有破坏任何东西(除了失败).如果停机时间导致某些事情变得严重,则使用严重性#1.

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

该程序以令人讨厌但不影响结果的方式行为不端.

该程序需要以一种明确定义的方式更好:更易于使用,实现新功能,运行更快等.

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

在我与之密切合作的中小型团队中,这套通用规则运作良好:

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

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

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

有些团队可能希望保留将问题从一个部门移动到另一个部门给管理人员,其他团队可能允许任何团队成员将问题移至(或返回)另一个团队.这可能归结为管理层的怀疑,或者仅仅是允许谁分配工作时间.

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

如果你正在使用Scrum,那么Triage团队可能就是scrum的主人,决定是否将问题拉入当前的sprint并正确分配优先级,如果它进入积压的话.