PDCA 质量环之实践-----测试推动开发质量的改进

网易云社区2018-06-12 10:46

引言


曾经, 我以为

作为一名测试工程师, 提交bug就是我的本职工作。 bug提的多,说明我牛。

直到有一天,我跟了一个烂项目(别慌, 是前任公司 ),逾期未交付, 做砸了~ 虽然我们测试团队报了上千个bug,可依然阻止不了项目的失败。

我的总监(负责开发和测试团队)在绩效考核时,评价我的工作:“bug报的多,并不能代表什么,只能说明开发质量烂”,“项目失败了,虽然不是你的原因,但按照个人贡献,我只能给你打个Meet(合格)。”

站在大boss的角度,是希望这个产品是成功的,高质量的。而线下bug多,都只是内耗。

那,我, 一名测试工程师,我能推动开发质量的改进吗?

有幸,在网易**项目中,基于PDCA质量管理理念, 做了一次实践。


1. 计划Plan
1.1 分析现状

项目负责人:
为什么测试员都已经报了这么多bug,还是会有很多线上问题?
整天在救火, 还怎么好好的做新需求啊!
究竟是开发代码质量差,还是测试员覆盖不全啊?

开发:
我需求都没开发完,你们就催着提测,催着上线。
哪有时间保证质量啊? 加班997, 都没时间和老婆生孩子了, 还要被责怪,我委屈啊委屈。

测试:
这bug都好low哦! block我测试了。
这个bug 怎么还没改好啊?都打回2次了。
啊? 怎么最后一轮还有bug啊!不开心。
可是,还是得硬着头皮上线。
宝宝心里虚啊!

项目负责人:
是时候整顿下了。

1.2 分析原因
既然是由bug引起的一场战乱,那咱就从bug着手。   于是,有了一周一次的bug回溯。

分析哪些bug?
  • 线上的bug
  • 线下Critical 和 Major 的bug
  • 罗列出可以通过开发自测解决的bug

分析什么?由谁分析? 怎样分析?
  • 每周挑选5个左右。
  • 分析 root cause, 以及落地改进方案。
  • 线下的bug改进方案由开发分析,线上的由开发和测试共同给出。
  • 每周周会,在测试发言环节,和所有人分享,其他所有人会进行补充并优化落地改进方案。
bug回溯示例:

1.3 制定计划
落地改进包括两点:技术改进和流程改进。流程改进包含以下内容:
  • 简单粗暴的bug请开发加强自测。
  • 开发加强 code review
  • 测试加强业务异常以及系统异常测试
  • 其他流程上的改进。
其他流程上的改进包含以下内容:
  • 对需求进行细化
  • 对接口进行详细定义和异常处理
  • hotfix 流程改进
  • 提测前客户端与服务器进行联调
  • 测试阶段进行bugbash
  • 整理并维护上线checklist

2. 执行Do

问题都已经暴露出来, 改进方案也有了。那么如何确保证这些改进真正地落实了。

纵观整个改进方案,最难落实的应该就是开发自测和代码评审.

开发先哭了,我们加班加点,周末无休, 需求都赶不完。还让我们自测,让我们代码评审。 我们也知道好处多多,but 时间啊, 时间啊~~

头儿发话了: 需求是一定要赶的(竞品太多),但是质量也得抓。

他捋了捋性感的胡须:“这样吧!下期需求,你们把自测和评审的时间都评估进去。随着你们对项目的逐渐深入, 对需求的评估能力应该会更加准确的。 到时候自测没做,可不能以时间为借口了哦!”

会哭的孩子有奶吃, 时间终归是有了。

那么怎么来监控开发自测和代码评审的过程呢? 毕竟这2个流程都是贯彻始终、持之以恒的事情!


2.1 开发自测的监控

我可能不用太关注开发冒烟通过率和完成度。流于形式的冒烟测试意义都不太大。

我主要跟踪的是bug。每个版本统计易自测的bug数(所谓易自测,说的狠一点,就是低端bug,哦,请原谅我是一个刀子嘴豆腐心的人)

说实在的,开发小哥们都是三观正、有理想的。谁愿意让人家指指点点bug多代码烂呢?

之前真的是流程的问题, 真的是流程的,流程的问题~


2.2 代码评审的监控

gitlab自带code review 功能。

跟踪者可以通过Activity 模块下的Comments 查看到所有评论。


可以每周统计一次数据, 包括评论条数、内容、修复情况。

示例:

现阶段统计还属于人肉操作, 同时也正在研究专业的代码评审的工具Gerrit,应该会让整个代码评审的工作更加规范一些, 也便于统计。


3. 检查Check

检查是对执行后效果的评估,是伴随着实施过程自始至终的,不断收集数据的过程。
版本时长:  计算开发开始--测试结束的时间。
总开发人日: 所有的开发人员在这个版本中投入的人日总和。
关注的指标: 总bug数除以总开发人日。
实践2个半月后,统计了近7个版本的指标, 大家可以看到,最后2个版本,指标降下来。
开发负责人: 质量好了,不用总是背锅了。
测试: 郁闷,找不到bug了(其实有找到几个old bug)
项目负责人: 测试找不到bug, 我也还是担心啊!
我:测试期间找不到bug,同样的测试资源,只会比以前更心细。 测试深度更深。 对测试环节,请放心~~~

4. 实践总结 Action
以上流程核心: 以bug回溯的方式来推动开发自测、代码评审以提高提测质量,进而提高产品质量。并且,不断收集晾晒数据。
开发鼓励坚持以这样的方式做质量改进原因如下:
  • 质量是真的在变好。提测后,发现的总bug数少了很多。
  • 开发把测试阶段修改bug的时间解放出来,可以做其他更有价值的事情。
  • 上线前所有人比以前更有底气了。
  • 整个团队规范性、自信心、士气、更好了。
经过这次实践,我对钱老师所言是认同的 嫌测试周期太长,试试开发自测吧!
因为整个产品开发阶段, 越早消灭bug,成本越低。 这就是为什么开展用例评审、开发自测的必要性!

附1: 图中的改进体系是PCDA的落地版。 经实践,现阶段对于网易**项目是行之有效的。



本文来自网易实践者社区,经作者李丹授权发布。