嫌测试周期太长?试试开发自测吧

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

1、引子:要提高测试效率


互联网产品竞争激烈,在生存的巨大压力之下,策划和运营人员们恨不得每一个需求都能秒级上线,这就给研发团队带来了巨大的压力。有时候,产品的老大很关注某一个功能点,希望能尽快上线,可是,他发现这个功能的开发只要10天,测试居然要7天,秋水都望穿了还没有上线,于是,老大们就忍不了了,一声怒吼:“要提高测试效率!

这确实是存在于现有研发流程的一个问题,但当我们深入地去分析这个问题的时候,发现测试人员很委屈:“说好的星期一提测的,可是星期一那个版本还有很多bug,根本就没法测,开发修改关键bug,最后拖到星期二才开始测试”;“进度定得特别紧张,开发非常忙,功能一开发完成就丢给测试了,但是还有很多bug,版本来回了好几次才逐渐收敛”;“为了赶项目进度,我们会在开发没完成的时候就帮忙找bug,所以测试时间看起来就会非常长”。

在这些情形中,我们发现开发人员和测试人员都是 三观很正的好同事,一个为了需求能尽快赶出来制定了非常紧张的时间表,一个为了能尽快发现bug提早进行测试。那究竟是哪里出错了呢?还有没有优化的空间的呢?

2、Bug的时间分析


看到这里,你可能会说:“别卖关子了,有啥宝赶紧献出来吧!”
还是请你稍安勿躁,为了表明这个帖子是一个技术贴,我们需要一些技术性的推理和演绎。
再来仔细地分析现有的流程:

开发一完成功能就把版本扔给测试人员,但bug太多,导致测试人员花时间报了很多bug,然后开发花很多时间修改bug;第二次的版本,可能质量还是很差;这样多次的版本往复。


我们来分析一下bug的代价:测试人员打版本、发现bug、报bug、跟开发沟通、验证bug,这其中都是有时间成本的。假设测试人员为每一个bug花费12分钟。


假设有一个项目,开发人员5个,测试人员1个;开发了14天(10个工作日),发现了100个bug。


那如果开发能加强自测的话,假设每个开发人员能花2个小时进行自测,靠自己的自测消灭了50个bug,只剩下50个,那我们来算一笔时间账吧。


Bug减少测试人员节省的时间=(100-50)*12分钟=600分钟  ~=1天。


那相当于,整个项目就延长了2个小时开发自测的时间,但是测试时间就缩短了1天,效率的提升是杠杠的。


当然,实际情况中数据可能会更好,两个因素:

  • 实际的情况中,测试人员为每个bug花费12分钟是假设的,实际的情况可能比12分钟还长,也就是说,效率可能提升得更多。
  • 这里我们也没计算沟通和修改bug给开发带来的时间花费,100个bug要跟测试沟通、要把代码调入脑内存、再修复还是需要很多时间的,如果能在代码在脑内存的时候消灭掉50个bug,那节省的时间说不定已经够抵掉2个小时的自测时间了。


3、试点的情况


另外,作为一篇严谨的技术贴,这里有一个假设是不得不说明的:开发人员靠2小时的自测真的能消灭50个bug??


根据我们的实践经验,真的是可以的,可以的,的。

我们在漫画、青果、Gacha、云捕等项目组做过尝试,开发人员进行充分的自测以后,版本的bug数量是真的可能减半的。


那开发和测试人员的主观感受如何呢?两个字: 酸爽
  • 测试人员说:“Bug减少了以后,流程走顺了,以前需要打5个版本,现在只需要打3个就刷刷搞定了。”
  • 开发人员说:“Bug减少了以后,流程走顺了,开发过程不那么乱了,自信心也提升了。”从我们试验的项目来看,开发还是挺愿意看到这种改变的。
所以,这真的是可以尝试的一个方向哦、真的哦、哦。

4、现有的经验和后续方向


根据我们的初步经验,有如下方式可以减少bug:
  • 加强测试用例的Review,跟策划、运营、开发一起,把测试用例的思路好好地Review一下。在这个过程中可以发现很多策划模糊和缺失的地方,提早修复这些问题减少bug。可以看作是需求评审的延伸环节。
  • 就是刚才讲的开发自测,测试人员写完用例以后,选择更多的用例让开发自测,有必要的话,事先教开发怎么自测。让开发、测试乃至整个项目组都树立起开发自测的意识,让这个环节能真正生效。
  • 代码review是能大幅度减少bug的,云捕产品经验也证明了这一点,不过要看项目的具体情况而定,有一些项目文化比较适合,有些项目需要慢慢来培养这种文化。

我们后续也会在这些方向上做更深入的探索,当然,还有更多其它的好的方式,靠你们创造。


最后说说我们的梦想吧,我们的梦想是:我想要一个舞台~~~~啊,对不起,我乱入了。



附上某产品推动开发自测和代码Review经验,作者是测试负责人李丹,干货满满哦: PDCA 质量环之实践-----测试推动开发质量的改进


本文来自网易实践者社区,经作者钱蓓蕾授权发布。