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