测试如何构建快速反馈的能力

2022-08-30   出处: CKL的思考空间  作/译者:CKL的思考

在团队活动中,反馈是一项非常重要的活动,只有收到反馈,大家才知道事情做到哪里了,做得怎么样了。在敏捷软件开发的核心价值观中,反馈也是核心之一。

01

反馈指的是:在信息的传播中,接受者对传播者发出信息的反映。反馈得很重要一个属性就是时间滞延。在测试活动中,笔者经常会团队的测试人员一个问题:开发提交了一段代码后,多久能收到质量反馈?是按天?按小时?还是按分钟?再往前一步,产品提供了一个Story,多久能看到功能实现?3天?1周?还是2周?

在测试活动中,如何构建快速反馈的能力,让团队感知到质量的现状,是非常重要的。也是测试Leader应该去思考和建设的。笔者总结了4个字:短、快、准、改

02

短,指的是反馈路径要短,在研发的每个环节都可以尝试去做反馈。

一般情况下,研发活动主要包含需求确认、研发过程、测试过程、部署上线几个核心的阶段。当一个需求的价值等到上线后,才得到不好的反馈,修复的成本是非常大的。因为反馈的链路越长,过程的浪费就越多,成本自然就高了(是不是很熟悉,我们经常讲的是缺陷发现得越早,修复成本越低。)。

所以,我们的反馈路径要短。于是测试就开始左移了,从需求侧就开始介入,快速反馈。具体做法可参考之前的文章,这里不展开说。(可参考从测试看需求需求端到端交付管理

03

快:自动化是必须的,可以和流水线结合起来。

就如前文提到的。开发提交一段代码,多久能得到反馈,如果需要1天后才知道,那就太慢了,这样的反馈也是比较浪费的。这时候就需要自动化手段的介入,不管是代码扫描还是自动化测试,又或者是质量门禁,都是快速反馈的体现。

以前开发吐槽的会是编译慢,现在吐槽的是测试慢,这么晚才发现问题。所以需要我们在代码被编译后,快速验证(不论是回归测试,还是新特性验证,不论是代码规范还是接口测试)。如果有问题,可以快速修复,避免流入到测试环境。

提到自动化测试,多提一个点。现在很多测试的小伙伴在做接口自动化的时候,需要自己手动去抓包,了解接口参数,然后再去做自动化。从学习的角度看,这个是没问题的。但是从团队的角度上看,这么做是很浪费时间的,ROI也会很低,因为接口什么时候变成了你都不知道。

自动化的前提是标准化。当自动化需要做很多兼容性来兼顾不标准的东西时,就没有必要自动化了,因为因果关系搞反了。

04

准:不要经常性地误报,增加不必要的成本。

快速反馈是好事,但如果反馈的问题是经常性误报,那还不如不报。这就需要我们更好地去建设我们的自动化机制,不要总是喊“狼来了”。

对于代码扫描,我们要结合团队现状,对部分规范进行取舍,或者对优先级进行重新评估,而不是从网上拿一份通用的规范直接就扫了,对于结果不做分析,可能很多严重的问题当下无法解决,或者因为项目的特性,某些规范并不适用等。要减少这些误报。

而针对自动化测试执行失败,需要做好分析,是什么问题引起的失败,是真的缺陷,还是因为环境问题、数据问题引起的误报?测试脚本的准确性和兼容性,也是非常重要的一项内容。需要测试人员持续去改进。

05

改:持续改进,螺旋上升,而不是停留在发现问题上。

所有的反馈都是为了解决问题,如果反馈的问题得不到解决,那么反馈就会变得毫无意义。要警惕杀虫剂效应,不能让反馈变成形式。当同样的问题多次重复出现时,我们就需要停下来,寻找根因并尝试去解决掉,而不是让问题一直存在,直到大家都麻木了。持续改进,螺旋上升,行动起来。

06

在某些情况下,我们需要跳出测试,从更高的视角来看待反馈。从单纯的测试角度来看,你只是解决了测试这个单点问题。从研发过程来看,你解决的是研发流程问题。从需求交付的角度来看,你解决的可能是公司业务问题。其中的差距,会让你的价值更大化,让你的护城河更加深厚,也就自我成长了。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
148° /1485 人阅读/0 条评论 发表评论

登录 后发表评论