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

lsekfe

经历过几家创业公司，发现大部分测试和开发人员，包括项目经理，对于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的范围可以由质量部门和项目组共同决定。