2016年奥斯卡文章之续传

网易云社区2018-06-12 11:50
没错,作者就是本人。
很荣幸,凭借此文章,获得了当年的实践者论坛奥斯卡奖杯。
这篇文章的核心思想是:
以bug回溯的方式来推动开发自测,以提高代码质量, 并且,不断地收集晾晒数据,来检验成果。

2017年,我们也并没有消停,仍然在推动开发自测的道路上探索。
的确,又往前稳稳地迈了一步。
你是不是很好奇, 我们还能玩出什么花样来?
的确,也不是什么新花样。
新功能,QA不再测试了!

吃瓜群众: 啊? 新功能不测试? 那谁测啊?
鄙人: 开发呀!
吃瓜群众: 开发那么厉害呀! 他们测试效果好吗?
鄙人: 当然好啦! 这个可是有数据支撑的。 
在自测的道路上,我们逐渐地把开发的习惯培养起来,现在可以说是高度信任了。

Plan

蓝色的数据代表, 开发自测的通过率
橙色的数据代表, QA执行通过率
戳完了图,大家肯定得到一个结论: 两组数组相差不大。
那既然相差不大, 为什么同样的用例,我们要执行2遍呢?
就那么不放心吗? 而你不放心的又是什么呢?

你不放心的不外乎两点:

第一,对测试用例的不放心
开发的自测用例,对于整个系统覆盖的完整度怎么样? 够吗?
不够!
但他们只需要保障自己开发的新功能,包括正常逻辑、异常逻辑、以及和其他模块耦合的功能
也就是功能点 100% 的用例。
这部分用例,理所应当是QA提供的。
而QA的重心也必须由测试执行,切换到用例设计上
而这不恰恰是我们QA的核心价值么?
当然,QA还需要像用户那样,做场景测试,俗话说就是多个功能点串起来的测试。
除此以外,还需要保证无兼容性问题。
请相信,我们还有 回归测试、 预发布测试、 线上验证,等多重环节来保障质量的。

第二,对于线上质量的不放心
如果QA不再测试功能点,会错过些什么?
我们从jira上拉取了2个月   8个版本的bugs
对所有的bug进行了归类分析,得到以下的数据
如果不做功能点的详细测试,一些细枝末节的bug可能就会放过了。
Normal级别的bug大概只会Catch到目前的77.4%,Minor 会更低点。
但是, 那又怎么样呢?整个团队对bug的态度,难道真的是零容忍么?
如果不是,那就放下QA对自己高标准高要求的自尊吧
退一万步讲,
互联网行业区别于传统行业,不就是快么!不就是修复成本低么!
通过以上数据的分析,我们明确了两件事情
第一,开发是完全有能力做功能点全自测的
第二,QA不做功能点测试风险是较小的

We Do

我们及时地把我们的想法传递给了项目经理,和开发领导。
项目经理近一年来,见证了测试在推动代码质量方面做的努力,也深切地感受这样的实践活动对项目团队带来的收益。
本着资源不浪费的原则,决定可以一试。

开发经理有所顾虑,这也可以理解,毕竟需要让开发同学来承担质量的风险了。
但是看到我们收集的数据,有理有据。
加之觉得测试这几个女同学平时都挺有责任心,做事很靠谱,合作很愉快,人也长得极其漂亮就答应了。
上面后半部分理由是我YY的。
但是,结果就是答应了。

而我们,得用更加积极的态度,更加多维的数据统计方式向团队来证明
开发功能自测+QA场景保证,这样的方式是有效的。
我们引入了一个新的数据统计的维度----变更代码覆盖率,来提升团队的发布信心。
每周在上线前,从CR平台(杭研质量保障部自研的平台)获取到变更代码覆盖率,
然后对代码未被覆盖的部分,作以分析,查缺补漏,及时补充手工或者自动化用例。
把最终的覆盖率发给项目团队的成员。
我们有了更多的时间,来维护自动化用例,我们的核心模块,行覆盖率一直保持在85%左右

当然,我们还必须得对开发的自测质量进行持续有效的跟踪。
对每个版本的发现的缺陷进行分析,评估是否可以通过自测用例发现,如果有这种现象,则需要及时组织用例执行人员进行回溯和总结,也趁机听听开发对测试用例的反馈。

Check

上面一张图,很好的诠释了我们推动开发自测的路程
第一个阶段,推动冒烟自测,开发bug率下降的效果立竿见影
第二个阶段,推全自测,bug率也由0.6,下降到0.4以内
第三个阶段, QA不再验收开发自测过的用例,bug率并没有明显下降,这也从另一个方面说明,开发与QA测试,无太大的差异,测试也无明显的遗漏。
但,阶段三,却能节约测试执行的时间, 使得进度节奏加快。 
大家可以看下图

7、8、9月份,开发人力上升的情况,现有的测试人力,仍能游刃有余, 而且,还能保障得更多。

Action

开发新功能点测试+测试场景保障的测试策略,目前已实践4个月,仍然会继续走下去。


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