小王是一个测试团队的新成员,遇上这个情况应该怎么办?

该用户已存在007

小王是一个测试团队的新成员, 这是他第一次参与研发流程. 他工作认真负责, 总能够准确快速地找出产品中的bug, 同时还能够协助开发团队找到root cause, 所以大家都很喜欢他.



但是随着项目的推移, 堆积起来的bug越来越多了. 因为进度滞后, 所以大家的压力都比较大. 慢慢地, 小王发现身边的情况有了些微妙的变化. 比如吧, 以前他找到一个bug, 大家都会鼓励他, 现在他找到些不那么严重的bug, 好象一些团队成员的脸色就不那么好看了. 另外呢, 他隐约地听说测试经理好像和开发经理有点矛盾了. 原因主要是进度跟不上, 开发那边想把一些前面决定要修的bug往后面推, 就是希望等到下一个版本再修.



于此同时, 小王的好朋友小马, 做了几年开发的, 悄悄给小王说. 现在进度落后, bug太多, 上面大老板看报表的时候不好看, 弄不好到头来大家都没有好果子吃. 现在就算再找多少bug出来, 来不及去修, 除了把报表弄得更加难看, 对最终客户也没什么好处, 是个吃力不讨好的事情...



小王正好有一个半年一次和测试总监面谈的机会.小王针对这个情况还专门归纳出下面几个问题. 如果您是测试总监, 您建议小王怎么处理目前的情况呢?
(明天我来公布测试总监的回答和我自己的一些看法)





1. 一般来说, 在项目准备阶段, 会树立一个缺陷等级 (bug bar), 定义缺陷的严重程度. 随着项目的进行, 这个缺陷等级应该发生变化呢, 还是应该保持不变呢?


2. 当发现一个bug后, 会根据缺陷等级来定义这个bug的严重度, 比如1级,2级或者3级. 一旦一个bug被发现并且赋予了对应严重等级后, 是否存在其他因素导致这个bug的现有等级发生变化呢? 比如研究后发现, 修复某一个bug可能需要花很多时间, 这个发现会导致这个bug的严重度变化吗?


3. 对于发现的bug, 修还是不修, 取决于哪些因素? 除了bug的严重程度和对用户的影响外, 目前团队的进度和资源对做决定是否有影响呢? 比如本来有些开始准备修的bug, 到了后来发现开发进度滞后了, 会不会就决定不去修这些bug了呢?

White_Chocolate

理想与现实的差距还是有的。

mentgmery

LS很强势,需要这样的测试人员

zjxyy88107

这件事说明一个问题！测试人员在公司的生存状态!换成我，我也不会妥协，Bug可以pending，但是不能一直拖下去，你们公司如果这样发展下去，迟早要出问题的！我现在会定期去查看Bug状态分析图，如果open的bug多的话，我会要求开发暂停新功能的开发，先处理Bug，我想这样是对公司，对客户，对自己负责，测试有时候要强硬一点！

faintman10

beryl_lin

非常同意3#的回复

black_tulip

藏着掖着不是个事，尽早和客户沟通，在什么时间点，交付一个什么状况的软件。达成一致就好办多了。严重度一般不会变，优先级会经常变。之前决定要解决的，之后是可能会重新决定暂不解决。

mentgmery

很有意思的一个案例，

先回答1,2,3
1. 个人认为不应该变化。
2. 严重等级一般不会发生变化，而发生变化的可能是优先等级，这是两个概念。
3. 修还是不修，主要是看这个BUG是否在进度的关键路径上或核心功能模块，如果在那么就必须干掉，否则可以postponed;进度和资源当然有影响，这些都是需要项目团队及早的做风险管理规划的，如果协调不好资源和进度，那么非关键路径上的问题可能会成为关键路径上的问题，那么这个时候就对团队的执行决策产生影响；发现的BUG应该都要修的，只不过会根据进度安排，把一些不重要的BUG推迟到下一个版本修复

archonwang

这几个问题自己大概考虑了下。简略说明如下：
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. 这种情况最好不要出现，一旦发生，即意味着项目可能会出现较大的不可控因素，导致质量的急剧下降。除非，这块功能不再使用，或之前的需求存在漏洞需要重新考量。