测试总监的第一封回信, 然后小王又问了第二个问题
前一篇文章中,提到了测试流程中关于bug定义, 流程方面的一些争论.
我之所以选择这个话题作为blog的第一篇文章, 因为我也有过类似的体会.
这里把这三个问题再列一下:
1. 一般来说, 在项目准备阶段, 会树立一个缺陷等级 (bug bar), 定义缺陷的严重程度. 随着项目的进行, 这个缺陷等级应该发生变化呢, 还是应该保持不变呢?
2. 当发现一个bug后, 会根据缺陷等级来定义这个bug的严重度, 比如1级,2级或者3级. 一旦一个bug被发现并且赋予了对应严重等级后, 是否存在其他因素导致这个bug的现有等级发生变化呢? 比如研究后发现, 修复某一个bug可能需要花很多时间, 这个发现会导致这个bug的严重度变化吗?
3. 对于发现的bug, 修还是不修, 取决于哪些因素? 除了bug的严重程度和对用户的影响外, 目前团队的进度和资源对做决定是否有影响呢? 比如本来有些开始准备修的bug, 到了后来发现开发进度滞后了, 会不会就决定不去修这些bug了呢?
回到上面的话题, 我这里先把测试总监的回答帖下来:
1. 缺陷等级 (bug bar)是根据产品质量标准来定义的. 在不同的产品周期(milestone), 缺陷等级标杆可以是不同的. 比如在临近项目结束,已经到了BETA的最后阶段, 或者马上就要RTM发布了, 这个时候的缺陷等级标杆就会非常的高. 这是为了防止项目后期regression的风险.
2. bug的严重程度,是把这个bug给客户带来的影响,同缺陷等级标杆比较得出来的. 只要这两个因素没有发生变化, 那bug的严重程度就不应该变化. 对于修复bug所需要的开销, 当前项目的进度等, 都不应该对bug的严重程度计算有任何的影响.
3. 一个bug修还是不修, 同样是有当前产品周期的缺陷等级标杆所定义的. 如果预先已经定义好了哪一个级别以上的bug, 必须在当前(milestone)修掉, 那就一定要修. 如果时间不够, 那只有延长当前项目周期. 或者极端的时候, 会评量是否需要裁减功能. 但总的来说, 对当前产品周期定义好的质量标杆才是修或者不修的标准. 当前bug数量, 资源, 进度什么的, 都不是考虑的因素.
上面的回答, 是小王和测试总监面谈后, 测试总监专门总结下来通过电子邮件发给小王的.
小王非常满意测试总监明确利索的回答. 但是, 这并不等于小王心中的阴霾就以扫而光了. 小王接下来又问了这样一个问题
"现在项目比较被动, 作为测试人员, 我会按照上面的标准, 尽量把产品缺陷提前找出来, 并且坚持上诉原则, 确保产品质量. 但是这么多bug都一定要坚持修的话, 看来推迟产品发布很难避免了. 那到了最后作工作总结的话, 作为测试人员, 既然我做好了测试工作, 也坚持了产品质量原则, 那产品延期是不是我就不需要承担责任, 反而应该得到奖励呢?"
请问, 测试总监的第二封email应该怎么回答呢?
PS:
如同园子里面的朋友卡通一下提到的那样, 这是没有正解的. 看了大家对前一篇blog的回复, 发现不同的人看待同样的问题, 角度和思维都有不少差异. 有的直接去考虑出现这种被动情况的根源在哪里, 有的追求解决当前问题的现实可行办法, 还有的认为测试人员的基本原则才是最重要的. 我觉得这样的讨论非常有意思, 同时也想听听各位对于软件测试, 有哪些感兴趣的话题?
总结一下各位朋友的观点,和网上其它渠道收集到的一些看法:
===============================
看法1:
1. bug等级应该分两种： 严重程度和优先程度， 严重程度是不会变的，优先程度在不同的阶段是不一样的
2. 严重程度和是不是有足够的时间修复是没有关系的，不能说这个人快死了，现在没时间医就说他还好着呢
3. 都有影响的，严重程度和进度都会影响到一个bug是不是应该修复，但是不是要修复bug不应该是开发人员自己决定的，也不应该是测试人员单独决定的，应该由开发，测试和PM共同决定，如果这个bug很严重，即使延期也必须修复，不那么严重，则可以推迟到下一个版本再做修复
===============================
看法2:
如果我是小王，那么此时我到是觉得我必须要尽职尽责，对目前系统存在bug进行归类总结，分出bug的优先顺序以及bug出现所属root case，并更具这些归类做一个整体的解决方案，然后尽可能的去和开发人员进行沟通，尽可能做到既不影响当前的开发进度又能解决这些bug，当然解决bug的前提是以及你掌握的优先级的，比如决策性的bug、逻辑混乱的bug等等那是必须需要当即进行修正的.
同时了，此时和老板进行交流时，我想就不会是用一堆bug来和老板面谈了，而是说目前系统存在了bug，而现在我制定了解决bug的方案，我也尽力说服大家来对bug做修改了，同时也保证了开发进度。
===============================
看法3:
1. 缺陷等级不一定等同于优先级。问题的严重程度并不一定取决于问题的技术性质。很多项目，问题是否能得到及时解决取决于该功能是否常用，影响面是否广大等因素。至于说到缺陷等级是否变更，我觉得要看你这个缺陷等级所要表述的是什么概念。
2. 看了这个问题，前面的问题，即缺陷等级，可能偏向于缺陷本身的性质这样一个概念。那么，的确存在相关因素会导致这个bug的修改优先级发生变化。例如：形象因素等等。
3.1. Bug修改与否，取决于较多因素，常见的是以下几种情况
3.1.1. bug本身的性质
3.1.2. Bug的影响面，是否会影响现行业务或对业务支撑造成不可弥补的错误
3.1.3. 不修改会存在巨大隐患么？
3.1.4. 客户关注
3.2. 客观而言，不会。有影响的只是项目最终交付的时间和进度计划。当然，随着项目推进，之前的bug可能会被冲叠，造成隐匿，这种情况的隐患极大。所以，必须强调的是Bug修改优先于新功能开发。
3.3. 这种情况最好不要出现，一旦发生，即意味着项目可能会出现较大的不可控因素，导致质量的急剧下降。除非，这块功能不再使用，或之前的需求存在漏洞需要重新考量。
===============================
看法4:
1. 个人认为不应该变化。
2. 严重等级一般不会发生变化，而发生变化的可能是优先等级，这是两个概念。
3. 修还是不修，主要是看这个BUG是否在进度的关键路径上或核心功能模块，如果在那么就必须干掉，否则可以postponed;进度和资源当然有影响，这些都是需要项目团队及早的做风险管理规划的，如果协调不好资源和进度，那么非关键路径上的问题可能会成为关键路径上的问题，那么这个时候就对团队的执行决策产生影响；发现的BUG应该都要修的，只不过会根据进度安排，把一些不重要的BUG推迟到下一个版本修复
===============================
看法5:
这件事说明一个问题！测试人员在公司的生存状态!换成我，我也不会妥协，Bug可以pending，但是不能一直拖下去，你们公司如果这样发展下去，迟早要出问题的！我现在会定期去查看Bug状态分析图，如果open的bug多的话，我会要求开发暂停新功能的开发，先处理Bug，我想这样是对公司，对客户，对自己负责，测试有时候要强硬一点！
===============================
上诉的看法我觉得没有谁对谁错. 因为不同的公司和不同的项目特点, 决定了解决问题的方法会各有不同. 从国内的不少技术社区了解到, 很多人觉得国内测试水平比较落后, 其中例子就有比如没有统一的规范, 对测试不够重视等. 这里我会尽我所能对测试领域做一些分析和讨论, 希望有所帮助.
