测试如何构建快速反馈的能力
https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247484172&idx=1&sn=a5b35d73685bb883cd0ccc09cecda980&chksm=c0fb1539f78c9c2f5fe11626c0c2745af01a704aff082510c48e58521cefb5a39a58766cd70a&cur_album_id=1979310371207184387&scene=189#wechat_redirect
在团队活动中,反馈是一项非常重要的活动,只有收到反馈,大家才知道事情做到哪里了,做得怎么样了。在敏捷软件开发的核心价值观中,反馈也是核心之一。
01
反馈指的是:在信息的传播中,接受者对传播者发出信息的反映。反馈得很重要一个属性就是时间滞延。在测试活动中,笔者经常会团队的测试人员一个问题:开发提交了一段代码后,多久能收到质量反馈?是按天?按小时?还是按分钟?再往前一步,产品提供了一个Story,多久能看到功能实现?3天?1周?还是2周?
在测试活动中,如何构建快速反馈的能力,让团队感知到质量的现状,是非常重要的。也是测试Leader应该去思考和建设的。笔者总结了4个字:短、快、准、改。
02 短,指的是反馈路径要短,在研发的每个环节都可以尝试去做反馈。
一般情况下,研发活动主要包含需求确认、研发过程、测试过程、部署上线几个核心的阶段。当一个需求的价值等到上线后,才得到不好的反馈,修复的成本是非常大的。因为反馈的链路越长,过程的浪费就越多,成本自然就高了(是不是很熟悉,我们经常讲的是缺陷发现得越早,修复成本越低。)。
所以,我们的反馈路径要短。于是测试就开始左移了,从需求侧就开始介入,快速反馈。具体做法可参考之前的文章,这里不展开说。(可参考从测试看需求、需求端到端交付管理)
03 快:自动化是必须的,可以和流水线结合起来。
就如前文提到的。开发提交一段代码,多久能得到反馈,如果需要1天后才知道,那就太慢了,这样的反馈也是比较浪费的。这时候就需要自动化手段的介入,不管是代码扫描还是自动化测试,又或者是质量门禁,都是快速反馈的体现。
以前开发吐槽的会是编译慢,现在吐槽的是测试慢,这么晚才发现问题。所以需要我们在代码被编译后,快速验证(不论是回归测试,还是新特性验证,不论是代码规范还是接口测试)。如果有问题,可以快速修复,避免流入到测试环境。
提到自动化测试,多提一个点。现在很多测试的小伙伴在做接口自动化的时候,需要自己手动去抓包,了解接口参数,然后再去做自动化。从学习的角度看,这个是没问题的。但是从团队的角度上看,这么做是很浪费时间的,ROI也会很低,因为接口什么时候变成了你都不知道。
自动化的前提是标准化。当自动化需要做很多兼容性来兼顾不标准的东西时,就没有必要自动化了,因为因果关系搞反了。
04 准:不要经常性地误报,增加不必要的成本。
快速反馈是好事,但如果反馈的问题是经常性误报,那还不如不报。这就需要我们更好地去建设我们的自动化机制,不要总是喊“狼来了”。
对于代码扫描,我们要结合团队现状,对部分规范进行取舍,或者对优先级进行重新评估,而不是从网上拿一份通用的规范直接就扫了,对于结果不做分析,可能很多严重的问题当下无法解决,或者因为项目的特性,某些规范并不适用等。要减少这些误报。
而针对自动化测试执行失败,需要做好分析,是什么问题引起的失败,是真的缺陷,还是因为环境问题、数据问题引起的误报?测试脚本的准确性和兼容性,也是非常重要的一项内容。需要测试人员持续去改进。
05 改:持续改进,螺旋上升,而不是停留在发现问题上。
所有的反馈都是为了解决问题,如果反馈的问题得不到解决,那么反馈就会变得毫无意义。要警惕杀虫剂效应,不能让反馈变成形式。当同样的问题多次重复出现时,我们就需要停下来,寻找根因并尝试去解决掉,而不是让问题一直存在,直到大家都麻木了。持续改进,螺旋上升,行动起来。
06
在某些情况下,我们需要跳出测试,从更高的视角来看待反馈。从单纯的测试角度来看,你只是解决了测试这个单点问题。从研发过程来看,你解决的是研发流程问题。从需求交付的角度来看,你解决的可能是公司业务问题。其中的差距,会让你的价值更大化,让你的护城河更加深厚,也就自我成长了。