缺陷管理:说一说bug的状态和解决方案

技术 同时被 2 个专栏收录
30 篇文章 0 订阅
7 篇文章 0 订阅

经历过几家创业公司,发现大部分测试和开发人员,包括项目经理,对于bug状态与解决方案竟然傻傻分不清楚,导致bug管理与统计上的混乱,在费尽了我的三寸不烂之舌团队成员解释之后,索性将这个问题做个整理写下来,希望对这些基本概念有所普及,现在大部分测试人员只关心学习高大尚的自动化测试,性能测试技术,却对一些基本概念的理解却是模糊不清,甚是让我感到担忧,希望本文对于入行测试的初学者,以及已经走在成长路上的测试人员有所帮助,也希望看到此文的开发,产品经理,项目经理也能提高一下认识,以做到更好的对bug进行管理。

笔者亲身经历例子:公司在teambiton中进行bug管理,bug的状态有待处理,处理中,已解决,已拒绝,暂不修复,无法重现,数据问题,关闭,重新打开等。典型的状态与解决方案不分,混为一谈。存在的问题是:已拒绝,暂不修复,无法重理等的问题要不要关闭?关闭后如何知道那些问题是修复过的?如何统计bug的修复率?如果开发将bug解为已拒绝,拒绝的原因是什么?如何统计所有未修复的bug中,重复,无法重现的等无效bug的数量和占比?在当时的情况下,唯一的办法就是只有修复并验证过的bug可以关闭,其他的bug保持状态不变(但也不能做到有效控制,有些bug没有修,因为各种原因被闭了,并且关bug时的描述有限,跟本无从判断到底有没有修复,追根溯源非常困难)。结果就是长期下来积累了大量的未关闭的bug,这此bug有哪些已经过期不存在了,哪些可以关了,哪些还需要后续跟进处理混乱状态。

这令我非常惊讶,一开始我还以为是个例,在经历过几家公司后,我发现或多或少都存在类似的bug管理上的问题(包括做项目管理工具的teambition的,在bug管理的流程的设计上,上本身就没有做到正确的示范和引导,jira在这方面就做的很好,状态和解决方案字段的默认设置已经区分的很明显了,无奈的是仍然有很多人企图更改jira的默认设置来对运转良好的流程进行扭曲,当然他们的用词叫做改进,优化)。我在微软(外包)工作时从来没有遇到过这种情况,微软工作流程已经非常成熟,以至于在我看来bug状态和解决方案的设计是bug管理系统的基础配置,根本不需要关注。

看来问题还是广泛存在的,有必要好好的梳理梳理,说道说道了。

先说办法,很简单,设计两个字段,区分状态与解决方案就好了,这并不是我的原创,我只不过是搬运成熟的做法而已。

bug的生命周期其实只有三种状态:

打开(open),已解决(resolved),关闭(closed)

注意:这里将重新打开(reopen)也算做打开

注意:已解决(resolved)不等于已修复(fixed)

bug的解决方案可以是多种多样,常用的如下:

  • 已修复(fixed)
  • 不予修复(won't fix)
  • 推迟处理(postpone)
  • 无法重理(not repro)
  • 重复(duplicate)
  • 设计如此(by design)
  • 外部原因(external)
  • 其他(other,如数据原因,环境原因,配置原因等)

另外,发现网友suixhcud对bug解决方案的解释特别有意思,而且二分贴切,给个链接: https://blog.csdn.net/a_dev/article/details/77773154

注意:已解决和关闭的bug有且必须有解决方案,打开的bug是不应该有解决方案的(因为还没有解决,哪儿来的解决方案?)

流程控制:

  • 当状态变为已解决和关闭时,解决方案为必填字段,否则不能改变状态。
  • 当状态变为打开或重新打开时,清空解决方案字段

很遗憾,teambition没有提供这样的流程控制,也没有地方可以设置这样的流程控制,而jira默认的bug流程控制就是如此。

好了,这么做,我们看一下问题是不是解决了呢?

例如:有同学会问,没有有了已拒绝,暂不修复的状态,开发同学处理bug时,遇到不好解决的,需要以后再修怎么办?测试误报无法重现怎么办?答,状态改为“已解决”,解决方案选“推迟处理”,“无法重现”。这里面让开发同学感到比较别扭的时,我明明没有解决这个问题,为毛让我选“已解决”?所以我就是我在上面提出的注意点了,因在中文表达中,解决了也有修复了的意思,我们所说的已解决,通常被理解为“已经修复”的意思。比如说一个开发跟项目经理说这一天他解决了10个bug,项目经理会觉得不错哦,小伙辛苦了,但是一看10个bug中有9个bug给的解决方案都是“不予修复”,实际上只修复了一个问题。想必项目经理内心应该会飘过几只。。。,他们应该会说,以后这种情况不要跟我说你解决了10个bug,实事求是,解决了1个就说1个。我建议在汇报工作时,应该区分使用“修复”和“解决”二字,做到有效沟通,避免歧义(如,我今天解决了10个bug,其中修复了1个,另外9个我认为不是bug,不需要修)。有同学会说,原来你的解决方案就是玩文字游戏啊。我想强调的是这并不是文字游戏,因为在团队协作中,沟通是非常重要的,采用bug管理工具对bug进行管理,也是沟通的一种手段(要不每天口头通知bug的状态和修改情况,绝对的混乱和没有效率啊)。

强调:正确的区分“已解决”和“已修复”,是理解状态与解决方案区别的关键。“已解决”只是状态,并不代表“已修复”。选择其他的方案,也可以视为对问题的“解决”。广义上说只要有“解决方案”,就是“已解决”。其实,resolved应用到bug处理流程上时,翻译为“已处理”更贴切,更不容易产生歧义,就是说这个bug已经处理过了,至于如何处理的,可以去看解决方案字段。已处理肯定不会等同于已修复,选择“不予修复”也代表处理过了,至少说明这个bug被看过了,并且做出了处理意见。这就是我们想要的,我们希望“已解决”或叫“已处理”这个状态,能代表“这个bug已经被人处理过了,处理人已经给出了解决方案”这个含义。

状态和解决方案各司其职,状态清晰了,妈妈再也不用担心bug的统计问题了。比如,统计所有未修复就关闭的bug,只要查询解决方案不等于“已修复”,且状态是“关闭”的bug就可以了。再比如,统计所有开发已经做出了响应,但是测试还没有处理的bug怎么办?筛选出所有“已解决”的bug就可以了,首先所有已解决的bug一定是开发响应过,选择了解决方案的,而测试处理过的要么就是关闭了,要么就是重新打开,所有仍处于已解决状态的,一定是待测试处理的。通过上面两个例子,是不是将原来头疼的问题,很简单就解决了呢?

 

最后总结下解决方案和状态的区别

状态

  • 状态记录bug当前处于某个阶段
  • 状态是相对临时的,是会随着bug的处理过程和而变化的
  • 状态最终趋向关闭
  • 适合做项目的进行中分析,不适合做事后统计分析(如未解决的bug数量,已关闭的bug数量等)

状态用在项目进行过程中,为项目的进度提供统计支持,统计结果是实时变动的。由于其最终的值都是关闭,故不适合做项目结束后的统计分析。

解决方案

  • 解决方案记录对一个bug的处理决定
  • 解决方案的填写只发生在bug的状态由“打开”变为“已解决”时,一般由开发人员填写
  • 当产品,项目经理,测试,开发等人员对解决方案存在争议时,需要开会讨论并形成最终决定
  • 解决方案是相对永久性的,形成决议后不再变化
  • 适合做事后统计分析(如bug的修复率,未修复bug数量,无效bug数量等)

注:关于统计bug的有效性,例如,可以将已修复,不予修复,推迟处理的bug视为有效bug,无法重现,重复,设计如此,外部原因等可以统计为无效bug,具体如何定义有效bug和无效bug的范围可以由质量部门和项目组共同决定

  • 3
    点赞
  • 0
    评论
  • 3
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页

打赏作者

boweiqiang

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值