本文首发于【林子的空间】
《敏捷团队的质量保障赋能》一文从敏捷价值观出发，结合Google、Amazon、Facebook等前沿大公司的质量赋能策略与实践，以及笔者多年在敏捷团队经历的赋能实践，跟大家一起探讨了敏捷团队质量保障赋能的必要性和落地策略。
本文通过分析近十来年《ThoughtWorks技术雷达》（以下简称技术雷达）上的各种技术、工具，从质量赋能角度来看相关技术发展所呈现出来的趋势，再次思考质量赋能该怎么做。
技术趋势
技术趋势主要有以下三个方面：
- CD技术、DevOps工具使得软件开发呈现全流程标准化趋势
- 大量测试和流程自动化工具助力标准化的实施
- 系统韧性成为质量的一部分，测试不再是质量保障的唯一方式
软件开发的全流程标准化
随着持续集成、持续交付、DevOps技术的发展，技术雷达上一系列的标准化技术和工具被采纳，主要集中在流水线以及流水线上的标准化工具（代码格式、提交规范等），包括专用于移动应用的流水线技术和工具，另外有平台级的方案——集成多套工具集的Azure DevOps和适用于机器学习的一整套端到端的持续交付策略CD4ML（机器学习的持续交付）。
其中，需要重点提及 Build pipelines（构建流水线）和Automated deployment pipeline（自动部署流水线）技术，这两个技术打通了从代码到发布的全流程标准化，具有标志性的意义。下面是技术雷达对这两项技术的描述：
- Build pipelines 构建流水线
在过去两年多的时间里，持续集成工具和平台的激增导致了构建和发布领域的实质性创新。 版本的分发就是其中之一，而另一个是可以在构建版本的各个阶段更好地利用自动化的方式。 构建流水线有助于更好地了解每个构建的质量以及所部署的环境。 构建流水线模因的自然扩展是采用持续部署技术，旨在将构建流水线扩展到生产环境中。 这依赖于内置在持续集成工具集中的自动部署技术和授权机制。 关键优势之一是能够快速可靠地将新功能投入生产环境。
- Automated deployment pipeline 自动部署流水线
采用持续交付意味着许多团队正在创建一个自动部署流水线，将代码一直带到生产环境中。流水线使得复杂的构建和部署活动链可以可视化，还具有可靠地跟踪每个阶段都会进行的构建工件的能力。已经有多家供应商在构建CI服务器，这些服务器不仅支持视觉元素，而且还把流水线视作一等公民。我们建议团队仔细研究这些产品，以避免浪费时间在没有足够支持的情况下将流水线塞入工具中。
大规模自动化助力标准化
全流程的标准化使得自动化更加容易，而大规模的自动化助力标准化更好的开展。自动化分为流程自动化和测试的自动化，从技术雷达上可以看到大量自动化相关技术和工具。其中流程自动化主要体现在基础设施管理和测试相关的工具、X即代码的方便自动化的技术、流程环节的自动化工具——自动发布和自动依赖检查等，测试自动化则包括测试分层技术、不同测试类型的技术和工具——消费者驱动的契约测试、API测试、前端测试、WebUI测试、性能测试工具等。
其中，要要特别强调的是Test at the appropriate level（合适的测试分层）技术，测试分层是精益测试、提高测试有效性的关键技术，对自动化测试的开展有着至关重要的作用。下面看看技术雷达怎么说：
- Test at the appropriate level 合适的测试分层
行为驱动设计BDD测试框架Cucumber的出现与浏览器自动化工具Selenium相结合，使得人们在浏览器级别广泛编写验收测试。但是，在运行测试成本最大的级别实现大量的测试是不合适的。 相反地，应该在尽可能接近代码的适当级别进行测试，以最大效率地运行测试。自动化测试应该由在合适层执行的验收和单元测试支撑，而浏览器级别的测试只是锦上添花。
系统韧性成为质量的一部分
随着业务形态、数据复杂度、技术架构和基础设施的发展，软件系统所处生态的日益复杂，不确定性因素增加，软件系统没法通过测试来保障100%的可靠性和正确性；另一方面，对速度的要求越来越高，从一个点子到开发出产品交付给最终用户的时间越短越好，同时，速度上的质量备受关注，快速获取反馈成为关键。因此，提高系统韧性，尽早发布到生产环境，以利用生产环境独有的数据来获取反馈，尽快的优化是应对策略。
技术雷达上有很多体现这一趋势的技术与工具：可观测性和监控、混沌工程相关技术和工具，还有1%金丝雀发布等。
这里要重点介绍Focus on mean time to recovery（关注平均恢复时间）和QA in production（生产环境下的QA）。
- Focus on mean time to recovery 关注平均恢复时间
传统上，运营团队希望缩短两次故障之间的平均时间。尽管避免故障显然仍然很重要，但是从云计算中获得的教训使我们期望发生故障，而将注意力集中故障的平均恢复时间上。持续交付自动化使发布快速修复程序变得更加容易，并且我们也看到了通过“生产环境免疫系统”快速发现故障的监控技术的增长。团队还成功地使用了语义监控和综合事务来以非破坏性的方式测试生产系统。这样，团队更有信心实现快速交付，可以减少对预生产环境测试的强调，并且对于已经发现的不断增长的安全漏洞列表的响应尤为重要。
从对平均故障间隔的关注转到对平均恢复时间的关注，表明快速获取反馈、快速交付、提高系统韧性的需求。
- QA in production 生产环境下的QA
传统上，QA主要关注在预生产环境中评估软件产品的质量。随着持续交付的兴起，QA开始转变为需要分析生产环境中的软件产品质量。这包括监控生产系统，设置警报条件以预警紧急错误，确定正在发生的质量问题，以及确定生产环境中的度量指标。虽然有些组织可能会走得太远而忽略了生产前的质量保障工作，但我们的经验表明，生产环境下的QA对于持续交付已经发展到一定程度的组织来说是一种宝贵的工具。
生产环境下的QA包含多种方式，详情可以关注我之前的文章《生产环境下的QA》。
质量赋能利器
标准化和自动化是质量赋能的必要利器
前面三个趋势总结说来体现在两个方面：标准化和自动化，这跟《敏捷团队的质量保障赋能》中介绍的大公司实践是一致的。其中，标准化包括标准流程和标准实践，自动化涵盖测试自动化和流程自动化。
真正的赋能利器
标准化和自动化很关键，但只是涉及到技术和工具层面，有了这些技术和工具是不是就能给团队进行质量赋能了呢？我们先来看下面两个问题：
曾听到不少相关反馈，比如说组织购买了自动化工具，觉得可以提升效能，于是减少测试人员，但是发现效能并没有得到很好的提升，原因是工具没有得到有效利用；同样地，也有工具厂商反应他们的工具卖出去急需对使用工具的人员进行赋能，让其了解工具的正确打开方式，了解工具真正带来的价值体现在哪里。
另一方面，随着持续交付技术和DevOps工具链的发展，大量原来需要QA手动完成的事情都被自动化了，也就是说QA的工作逐渐被取代。在这样的趋势下，QA是否还有存在的价值成为颇受关注的问题。
基于这样的趋势现状，根据三级QA能力模型，QA需要从普通的质量保障工作者转变为质量倡导者，承担起赋能者的职责，去给团队不同角色进行质量赋能，帮助团队提高质量意识，更好地理解质量目标以及正确的质量保障方式。
因此，真正的赋能利器包括标准化、自动化和质量倡导者QA。
质量赋能之道
团队的质量赋能是团队的事情，要实现成功的赋能会受到很多因素的影响，光有赋能利器还不够，更为关键的还有以下几个方面：
- 文化认知方面
要营造免责文化，鼓励团队成员创新、勇于试错，持续改进，不断发展。
要营造团队整体负责的质量文化，鼓励大家发挥主观能动性，行使质量所有权。
- 目标驱动
目标是引导团队往正确方向前进的关键，质量赋能需要有明确的质量目标驱动。要实现团队质量赋能，要做到团队为质量负责，质量目标需要在团队内达成共识，要让每个人都清晰理解这个目标。
- 策略指导
有了目标，还需要有清晰的质量策略来指导，团队在对策略达成共识的前提下，每个人发挥各自的优势，高效达成目标。
策略会受到多重因素的影响，每个阶段团队面临的急需要解决的问题也会不一样，显然策略需要适应这种不同，质量策略需要做到持续地演进。
- 能力建设
工具不能解决根本问题，人是非常关键的因素，组织要关注人员能力的培养。团队的质量赋能，需要团队进行充分地沟通和协作，要注意培养团队人员这方面的能力；另外，对于交付价值的正确理解至关重要，需要以价值驱动开展一切工作，包括人员能力的培养。
写在最后
关于团队质量赋能，需要谨记如下几个方面：
- 团队质量保障赋能是大势所趋，组织需要引起重视；
- 工具不是万能的赋能利器，QA需要转变为赋能者、质量倡导者；
- 文化认知、质量策略、人员能力不能成为质量赋能路上的绊脚石。
