首页手记怎么让研发做好他们不重视但是对测试很重要的事情？

怎么让研发做好他们不重视但是对测试很重要的事情？

标签：

测试

一个人有了坚实的自我，他在这个世界上便有了精神坐标，无论走多远都能够找到回家的路。

——周国平

问题

作为测试人员，质量保障工作者，经常会面临各种各样的困难，比如：

突然接到紧急需求或者故障单的验证，导致原本工作计划被中断，这还不算恼火，最让人恼火的是时间本来就紧张，却又在评估紧急需求的测试范围上耗费了大量时间；（测试范围不清晰）
送测版本中，出现了很多违反设计标准的bug，我们花了很多时间在提bug、验bug、研发也花费了相当一部分时间去修改这类bug。问题是这类bug好像根本不应该出现；（设计规范类bug）
研发提交了一个新版本，在这个版本中只修复了一个bug，回归通过上线后，却出现了几个以前没有的新问题，分析后发现是修复该bug时引入的！（测试人员不清楚回归范围）
研发修改了一个小功能，为了不漏测，测试人员把系统做了一轮完整的遍历（测试人员不清楚回归范围）。
提交了一个偶发性bug，研发回复说修复了。然后测试人员试了几遍没有再复现就把bug关闭了。结果到了线上以后又出现了（研发可能根本没有修改代码）；
发现了一个以前出现过得bug，想不起这个bug的原因和解决方式了，也没有记录，只能重新分析一遍；（经验没有积累）
在线上发现了一个bug，发紧急补丁修复了，过了一会又发现了另外一个bug，分析后发现跟第一个bug是同一个原因导致的；（研发做bug分析时不够充分）
系统运维人员的能力大都是靠经验和时间积累成长下来的，组员之间的经验没有很好的传递，这导致线上出现以前出现过得问题后，运维新手不能很好的应对，导致本该他们的工作又转移到研发和测试人员身上来。（经验没有积累和传递）

基于这种情况，笔者提出了两项需要研发部门配合的改进措施。

第一件是要求研发人员在修复bug后，在bug备注中添加必要的说明，包括“bug的原因”“怎么修改的”“这样修改会有哪些影响”；第二件工作是要求研发在需求提测时，以文字形式说明送测版本修改的内容和影响范围。其目的，一是让研发帮忙确认测试范围，其次避免研发在一些缺陷上没有找到真正的原因，再次是通过这样的方式，分析线上是否还存在未发现的可能存在的问题（问题7）

老话说“上医治未病”。测试人员，作为项目的“医生”，我也希望部门从当前的“事后”检查，转移更多精力到“事前”的预防和“事中”的控制上来。

推行这两项措施对质量提升有多少帮助呢？投入产出值得吗？

可以肯定的是，推行这项工作从一定程度上解决了开篇提到的那些问题，给测试人员的工作带来很多便利。对测试经理来说，也提供很多培训素材和工作汇报的内容；

但目前在“质量提升”和“研发效率降低”两方面还没有很准确的结论。也没有很直接的证据表明，后期产品质量状况的改善跟推行这项工作有多大的关系。

工作推行

这两项工作想要推行成功，需要考虑多种条件，比如公司和团队的性质、项目阶段、团队氛围、以及要推行的范围等，所以前期一般不会很顺利。

在上面说的因素都不是问题之后，或者说已经进入推行阶段，仍然很可能会出现其他问题，比如研发人员虽然作了备注但格式不符合要求，有人备注有人没有......

原因是什么？

我听到最多的声音就是忙。

我能理解，研发的压力确实很大，特别是作为一家互联网公司+创业公司，有时为了赶上进度，很多人甚至连续熬夜奋战很多天。在这种情况下，每个研发人员都把自己的精力放在重点工作上，对测试部提出来的流程和质量改进的问题难免会有一些疏忽。

还有其他原因吗？

我觉得，研发之所以不理睬我们的要求，还有一个可能的原因是研发人员没有意识到他们的一些做法给质量带来的影响，没有理解这种措施对质量的意义。