最新博客
最新资源下载
PDCA 质量环之实践-----测试推动开发质量的改进
活动主持人2018-06-12 10:46引言
曾经， 我以为
作为一名测试工程师， 提交bug就是我的本职工作。 bug提的多，说明我牛。
直到有一天，我跟了一个烂项目（别慌， 是前任公司 ），逾期未交付， 做砸了~ 虽然我们测试团队报了上千个bug，可依然阻止不了项目的失败。
我的总监（负责开发和测试团队）在绩效考核时，评价我的工作：“bug报的多，并不能代表什么，只能说明开发质量烂”，“项目失败了，虽然不是你的原因，但按照个人贡献，我只能给你打个Meet（合格）。”
站在大boss的角度，是希望这个产品是成功的，高质量的。而线下bug多，都只是内耗。
那，我， 一名测试工程师，我能推动开发质量的改进吗？
有幸，在网易**项目中，基于PDCA质量管理理念， 做了一次实践。
- 线上的bug
- 线下Critical 和 Major 的bug
- 罗列出可以通过开发自测解决的bug
- 每周挑选5个左右。
- 分析 root cause, 以及落地改进方案。
- 线下的bug改进方案由开发分析，线上的由开发和测试共同给出。
- 每周周会，在测试发言环节，和所有人分享，其他所有人会进行补充并优化落地改进方案。
- 简单粗暴的bug请开发加强自测。
- 开发加强 code review
- 测试加强业务异常以及系统异常测试
- 其他流程上的改进。
- 对需求进行细化
- 对接口进行详细定义和异常处理
- hotfix 流程改进
- 提测前客户端与服务器进行联调
- 测试阶段进行bugbash
- 整理并维护上线checklist
问题都已经暴露出来， 改进方案也有了。那么如何确保证这些改进真正地落实了。
纵观整个改进方案，最难落实的应该就是开发自测和代码评审.
开发先哭了，我们加班加点，周末无休， 需求都赶不完。还让我们自测，让我们代码评审。 我们也知道好处多多，but 时间啊， 时间啊~~
头儿发话了： 需求是一定要赶的（竞品太多），但是质量也得抓。
他捋了捋性感的胡须：“这样吧！下期需求，你们把自测和评审的时间都评估进去。随着你们对项目的逐渐深入， 对需求的评估能力应该会更加准确的。 到时候自测没做，可不能以时间为借口了哦！”
会哭的孩子有奶吃， 时间终归是有了。
那么怎么来监控开发自测和代码评审的过程呢? 毕竟这2个流程都是贯彻始终、持之以恒的事情！
我可能不用太关注开发冒烟通过率和完成度。流于形式的冒烟测试意义都不太大。
我主要跟踪的是bug。每个版本统计易自测的bug数（所谓易自测，说的狠一点，就是低端bug，哦，请原谅我是一个刀子嘴豆腐心的人）
说实在的，开发小哥们都是三观正、有理想的。谁愿意让人家指指点点bug多代码烂呢？
之前真的是流程的问题， 真的是流程的，流程的问题~
gitlab自带code review 功能。
跟踪者可以通过Activity 模块下的Comments 查看到所有评论。
可以每周统计一次数据， 包括评论条数、内容、修复情况。
示例：
现阶段统计还属于人肉操作， 同时也正在研究专业的代码评审的工具Gerrit，应该会让整个代码评审的工作更加规范一些， 也便于统计。
- 质量是真的在变好。提测后，发现的总bug数少了很多。
- 开发把测试阶段修改bug的时间解放出来，可以做其他更有价值的事情。
- 上线前所有人比以前更有底气了。
- 整个团队规范性、自信心、士气、更好了。
