小型团队的软件缺陷跟踪流程

本文简要介绍适用于小型开发和测试团队的缺陷跟踪流程,是作者在学习软件项目管理方法的过程中撰写的总结。

缺陷的定义

缺陷一词的含义不仅包括各种BUG,还包括软件产品的功能不全和用户体验不佳之现象。BUG大多是由于开发团队的疏忽和考虑不周导致的,是典型的软件缺陷。功能不全的缺陷大多源于团队沟通不畅,例如需求分析时遗漏功能点,开发人员未正确理解需求,需求和设计变更未及时传达至团队成员等。用户体验不佳则是软件设计层面的问题,相对而言多是严重程度较低的缺陷。性能缺陷一般导致用户体验下降,但是在实时软件中会产生更严重的后果:一款以5FPS运行的游戏不会获得玩家,无人机在控制软件无法按时控制电机时就会坠毁。

缺陷的严重程度

应当在缺陷说明文档中定义缺陷严重等级并描述缺陷严重程度,因其有助于开发人员决定缺陷修复的优先级并安排工作时间。不是所有缺陷都需要修复。对于大型软件,定位和修复一个并不显著影响用户使用的BUG可能带来高昂的成本和引入新缺陷的风险。许多游戏中物理引擎缺陷导致的物件小概率“起飞”就是一种修复性价比较低的缺陷。

  • 致命。导致系统崩溃、重要数据丢失或泄露的缺陷。触及致命缺陷将导致软件对用户失去价值,并可导致无法挽回的损失。
  • 严重。部分功能不可用的缺陷。
  • 一般。导致软件功能“降级”,如运行缓慢的缺陷,或者需求实现不完整,个别功能点缺失的问题。
  • 提示。作为技术人员可以明显察觉,但对实际用户影响有限的缺陷。
  • 建议。软件中尚有改进空间之处。例如,建议添加某些提示文字,建议对界面作出微小改动等。

软件缺陷处理流程

本文介绍小型团队(例如,十人以下)的缺陷管理流程。对于此种规模的团队,往往直接略去各种审核、分配、评审环节。尽管如此,下图中给出的缺陷状态流转图仍然适用于小型团队,只不过对缺陷的处理办法要由测试和开发人员自行把关。这样自我管理的方式要求团队内信息沟通顺畅,因此非常有必要使用各种项目管理工具(包含缺陷管理模块)整合缺陷处理流程,列出所有缺陷的状态和处理人,使所有成员都对项目进展做到心中有数,并了解同事手中正在开展的工作。

腾讯项目管理工具TAPD内的缺陷列表

下面介绍缺陷状态的流转过程,即缺陷从发现到处理完毕(修复或拒绝)的整个过程。

缺陷状态流转示意图

新:缺陷的发现

理想条件下,我们希望所有缺陷都是由测试人员发现的。这意味着生产环境中软件将是完美的。实际上,测试团队总是会漏过一部分(也许是大多数)缺陷,最终由运维人员和用户发现。测试人员由于具有发现缺陷的目的性,提交缺陷时可以且应当提供发现缺陷时的具体运行状态和环境,以便开发人员定位问题。运维人员由于对技术有较多了解,也可以在缺陷流转至开发人员前就进行分析。用户提交的缺陷则可能只包含对问题的模糊描述,最难以定位。测试、运维和客服都应当通过统一的平台记录缺陷,不同来源缺陷所占比例就可以在一定程度上反映团队控制缺陷的能力。

缺陷描述包含的字段数可多可少,但是除功能不全外的缺陷描述至少应当包括以下几项内容:

  • 未通过的测试用例(测试阶段)或/和发现缺陷的场景与现象(部署和运行阶段)。显然,这是开发人员复现并定位问题的基石。
  • 可能与缺陷相关的软件模块及其负责人。有助于开发团队分配任务,将缺陷交给最熟悉相应程序逻辑的人。
  • 发现缺陷时的软件运行环境。有助于重现缺陷。对于软件的兼容性问题处理尤其重要。
  • 发现缺陷时使用的软件版本。有助于定位引入缺陷的时间和位置。
  • 缺陷的严重程度。
  • 缺陷的添加者。便于处理人与添加者进行进一步沟通。

更详细的缺陷报告无非是希望进一步降低沟通成本并提高团队成员的工作效率。为此可以引入的内容还有:重现规律,总结自大量的测试用例和用户反馈,对于复杂BUG的处理大有裨益。缺陷的引入版本,由定位缺陷的开发人员填写,利于团队对软件迭代过程进行评价总结。总之,撰写缺陷描述文档的核心在于尽可能多地提供对解决问题有价值的信息,而不是划清界限,推卸责任。

接受/处理:缺陷定位与处理及任务分配

如前文所言,本文介绍的流程中不含任何领导——假设我们有一群水平优良,工作自觉的程序员,他们自己负责在团队中分配缺陷处理的任务。分配任务的原则无非是以下两条:“谁污染,谁治理”和“各尽所能”。引入缺陷的程序员当然最熟悉自己写下的“问题代码”,同时也对其负有自然的责任。“各尽所能”要求团队成员自觉地处理自己最擅长的问题,使团队效率达到最高,但是同时也对成员的个人素质提出了更高的要求。

当开发人员修复完成后,应当将缺陷出现的具体原因以回复形式书写于缺陷描述文档之下,此为后文回归测试所必须,也供缺陷未正确修复时或今后缺陷重新出现时负责同一问题的开发人员参考。然后,开发人员将缺陷状态置为“已解决”,指程序员已经修复缺陷,等待回归测试。

TAPD平台上缺陷由接受/处理转为已解决状态
此时可以为缺陷的回归测试指定一名测试人员

已解决和已验证:回归测试验证修复效果

开发人员修复缺陷后,需要由测试人员再次测试缺陷所在模块的所有测试用例,称之为回归测试。绝不应当只测试先前未通过的测试用例,因为新的修改可能在软件各个地方引入新的缺陷。回归测试的最佳实践是重新测试整个软件,但这只能在完善的持续集成与自动化测试条件下可以实现。对于手工测试,应当根据开发人员提供的缺陷定位测试与之直接耦合的所有模块。

以上方法是针对测试阶段发现的问题所制定的。对于运维和客户发现的问题,测试用例已经漏过它们,因此只能用于测试是否引入新缺陷。此时,要求测试人员根据缺陷内容与开发人员提供的缺陷定位针对性地设计新的设计用例,以覆盖先前未覆盖的程序逻辑。

回归测试通过后,由测试人员将缺陷状态标记为“已验证”。

重新打开:缺陷处理中的意外情况

缺陷重新打开由以下三种情况:1.未通过回归测试,即缺陷未被完全修复或修复过程引入额外的缺陷。2.通过回归测试,但是在生产环境中同一缺陷再次出现。3.重新打开已拒绝的缺陷。第二种情况自然不是我们想见到的。一旦出现,就要重走一遍全套流程。此时,新缺陷和重新打开的缺陷实质上是一致的。

已验证到已关闭:也许是领导的专属流程

缺陷处理流程中,这是最后一个也是唯一一个为领导设计的流程——确认处理流程完成,员工尽职尽责,于是标记为“已关闭”,标志着研发团队又成功挺过一个难关。这里,我们却不妨将其分配给缺陷的发现者——最初的测试、运维人员或者客服,由他们确认最初的问题确实已被正确理解并解决,然后将缺陷标记为已完成状态。

已拒绝

由于各种原因,可能并不需要或不能对提出的缺陷进行响应。已拒绝的缺陷值得团队付出额外注意力,因为它们大多是团队沟通不良的结果,并可能在成员间引起不必要的纠纷

  • 问题描述不清。由缺陷提出者明确问题后,再将缺陷标记为重新打开。
  • 缺陷无法复现。缺陷提出者确认问题后,保留未处理的缺陷继续跟踪观察。
  • 设计如此。往往是产品与众不同之处,也可能是披着feature外衣的BUG。
  • 转为需求、变更需求。缺陷描述的是目前产品不具有的功能,且此功能经商讨认为值得增添,于是转为需求。
  • 挂起(suspend)/延期处理。这类问题由于解决十分困难,或者对相应模块的修改有风险(如改动架构)。相当于比最低优先级更低的优先级,一般需要在充分讨论的基础上才能延期/挂起缺陷。

缺陷处理的优先级

缺陷的严重程度直接决定了缺陷修复的优先级。一般而言,缺陷的修复遵循先来后到的原则。对于严重影响服务稳定可用的缺陷,则应在队列中优先修复,直至立即开展工作进行修复。对于修复过于困难又无严重影响的缺陷,可以延期修复,即具有低于后来的普通缺陷的修复优先级。

使用缺陷管理工具时,我们可以以优先级为首要标准安排修复工作,即所有高优先级缺陷修复完成后,才能轮到普通优先级的缺陷。也可以综合考虑缺陷打开的时间和优先级,例如高优先级的缺陷比提出时间较早15天以内的普通缺陷提前修复,15天以上的普通缺陷则还是先行修复,避免老旧问题积压。

附录:测试经理和开发经理

本文中没有出现这两个角色。若团队内确有这开发与测试经理,则他们应有审核把关和工作进度控制的职责。测试经理需审核测试团队提出的缺陷,并在测试团队内分配回归测试工作。开发经理决定缺陷处理的优先级,并负责在开发团队内分配缺陷修复工作。遇到缺陷多次重新打开或被拒绝又无法达成一致的情况,开发经理和测试经理可以主持缺陷评审会议,商讨解决办法。

发表评论

电子邮件地址不会被公开。 必填项已用*标注