互联网产品竞争激烈,在生存的巨大压力之下,策划和运营人员们恨不得每一个需求都能秒级上线,这就给研发团队带来了巨大的压力。
有时候,产品的老大很关注某一个功能点,希望能尽快上线,可是,他发现这个功能的开发只要10天,测试居然要7天,秋水都望穿了还没有上线,于是,老大们就忍不了了,一声怒吼:“要提高测试效率!”
在这些情形中,我们发现开发人员和测试人员都是三观很正的好同事,一个为了需求能尽快赶出来制定了非常紧张的时间表,一个为了能尽快发现bug提早进行测试。
那究竟是哪里出错了呢/h2>
还有没有优化的空间的呢/h2>
看到这里,你可能会说:“别卖关子了,有啥宝赶紧献出来吧!”
还是请你稍安勿躁,为了表明这个帖子是一个技术贴,我们需要一些技术性的推理和演绎。
再来仔细地分析现有的流程:
开发一完成功能就把版本扔给测试人员,但bug太多,导致测试人员花时间报了很多bug,然后开发花很多时间修改bug;第二次的版本,可能质量还是很差;这样多次的版本往复。
测试人员打版本、发现bug、报bug、跟开发沟通、验证bug,这其中都是有时间成本的。假设测试人员为每一个bug花费12分钟。
测试人员说:“Bug减少了以后,流程走顺了,以前需要打5个版本,现在只需要打3个就刷刷搞定了。”
开发人员说:“Bug减少了以后,流程走顺了,开发过程不那么乱了,自信心也提升了。”从项目反馈来看,开发还是挺愿意看到这种改变的。
所以,这真的是可以尝试的一个方向哦~
根据我们的初步经验,有如下方式可以减少bug:
加强测试用例的Review,跟策划、运营、开发一起,把测试用例的思路好好地Review一下。在这个过程中可以发现很多策划模糊和缺失的地方,提早修复这些问题减少bug。
就是刚才讲的开发自测,测试人员写完用例以后,选择更多的用例让开发自测,有必要的话,事先教开发怎么自测。让开发、测试乃至整个项目组都树立起开发自测的意识,让这个环节能真正生效。
代码review是能大幅度减少bug的,不过要看项目的具体情况而定,有一些项目文化比较适合,有些项目需要慢慢来培养这种文化。
这是一篇可以让开发和测试人员和谐相处,共同进步的文章,希望测试童鞋多多转载给身边的开发童鞋看看哟
现在我邀请你进入我们的软件测试学习交流群:【】,备注“入群”, 大家可以一起探讨交流软件测试,共同学习软件测试技术、面试等软件测试方方面面,还会有免费直播课,收获更多测试技巧,
喜欢软件测试的小伙伴们,如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一 键三连哦!
文章知识点与官方知识档案匹配,可进一步学习相关知识Python入门技能树桌面应用开发Tkinter208261 人正在系统学习中
微信公众号 自取测试学习教程 | 源码 | 解答 | 交流群来源:测试界的飘柔
声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!