一,问题
作为测试人员,质量保障工作者,经常会面临各种各样的困难,比如:
突然接到紧急需求或者故障单的验证,导致原本工作计划被中断,这还不算恼火,最让人恼火的是时间本来就紧张,却又在评估紧急需求的测试范围上耗费了大量时间;(测试范围不清晰)
送测版本中,出现了很多违反设计标准的 bug,我们花了很多时间在提 bug,验 bug,研发也花费了相当一部分时间去修改这类 bug.问题是这类 bug 好像根本不应该出现;(设计规范类 bug)
研发提交了一个新版本,在这个版本中只修复了一个 bug,回归通过上线后,却出现了几个以前没有的新问题,分析后发现是修复该 bug 时引入的!(测试人员不清楚回归范围)
研发修改了一个小功能,为了不漏测,测试人员把系统做了一轮完整的遍历(测试人员不清楚回归范围).
提交了一个偶发性 bug,研发回复说修复了.然后测试人员试了几遍没有再复现就把 bug 关闭了.结果到了线上以后又出现了(研发可能根本没有修改代码);
发现了一个以前出现过得 bug,想不起这个 bug 的原因和解决方式了,也没有记录,只能重新分析一遍;(经验没有积累)
在线上发现了一个 bug,发紧急补丁修复了,过了一会又发现了另外一个 bug,分析后发现跟第一个 bug 是同一个原因导致的;(研发做 bug 分析时不够充分)
系统运维人员的能力大都是靠经验和时间积累成长下来的,组员之间的经验没有很好的传递,这导致线上出现以前出现过得问题后,运维新手不能很好的应对,导致本该他们的工作又转移到研发和测试人员身上来.(经验没有积累和传递)
基于这种情况,笔者提出了两项需要研发部门配合的改进措施.
第一件是要求研发人员在修复 bug 后,在 bug 备注中添加必要的说明,包括 "bug 的原因"" 怎么修改的 ""这样修改会有哪些影响";第二件工作是要求研发在需求提测时,以文字形式说明送测版本修改的内容和影响范围.其目的,一是让研发帮忙确认测试范围,其次避免研发在一些缺陷上没有找到真正的原因,再次是通过这样的方式,分析线上是否还存在未发现的可能存在的问题(问题 7)
老话说 "上医治未病".测试人员,作为项目的 "医生",我也希望部门从当前的 "事后" 检查,转移更多精力到 "事前" 的预防和 "事中" 的控制上来.
推行这两项措施对质量提升有多少帮助呢? 投入产出值得吗?
可以肯定的是,推行这项工作从一定程度上解决了开篇提到的那些问题,给测试人员的工作带来很多便利.对测试经理来说,也提供很多培训素材和工作汇报的内容;但目前在 "质量提升" 和 "研发效率降低" 两方面还没有很准确的结论.也没有很直接的证据表明,后期产品质量状况的改善跟推行这项工作有多大的关系.
工作推行这两项工作想要推行成功,需要考虑多种条件,比如公司和团队的性质,项目阶段,团队氛围,以及要推行的范围等,所以前期一般不会很顺利.
在上面说的因素都不是问题之后,或者说已经进入推行阶段,仍然很可能会出现其他问题,比如研发人员虽然作了备注但格式不符合要求,有人备注有人没有......
二,原因是什么?
我听到最多的声音就是忙.
我能理解,研发的压力确实很大,特别是作为一家互联网公司 + 创业公司,有时为了赶上进度,很多人甚至连续熬夜奋战很多天.在这种情况下,每个研发人员都把自己的精力放在重点工作上,对测试部提出来的流程和质量改进的问题难免会有一些疏忽.
还有其他原因吗?
我觉得,研发之所以不理睬我们的要求,还有一个可能的原因是研发人员没有意识到他们的一些做法给质量带来的影响,没有理解这种措施对质量的意义.
当然,还会有其他的一些原因,比如关系不到位.
来源: https://www.cnblogs.com/scios/p/8274415.html