大家可能关注到双态 IT 联盟前一阵发布了一个测试敏捷化成熟度评估模型，不断有小伙伴问到我关于这个成熟度评估的问题，我发现大家很自然地把这个跟敏捷测试成熟度画上了等号，不过这不是 Thoughtworks 开发的，我也不是很清楚。为此，我特地进行了一番调研，希望我这篇文章的解读能解答大伙大部分的疑问。
我们先尝试从字面意思来理解一下，对于以下两个术语大家都比较熟悉：
数据匿名化 => 匿名数据：通过匿名化技术对数据进行处理，使得数据变成匿名的，也就是得到匿名的数据
存储虚拟化 => 虚拟存储：通过虚拟化技术对存储进行处理，使得存储变成虚拟的，也就是得到虚拟的存储
这两个例子，相信大家都能理解没有问题。关于测试敏捷化，类似地，从字面意思可以这样理解：
测试敏捷化：通过敏捷化的方式（可能包括技术、流程、实践等）对测试进行处理，使得测试变成敏捷的，得到了“敏捷的测试”
那么，“敏捷的测试”是否等同于“敏捷测试”呢？从字面意思来看，似乎是等同的。但事实如何，需要对两者有深入的理解才可以下定论。
01 相关概念
1. 敏态与稳态
为了更好地解释，有必要先介绍什么是敏态与稳态。
在数字化转型时代，企业一方面需要适应数字化时代快速变化的市场需求，另一方面需要保持关键业务的安全可靠和稳定性，传统的 IT 需要同时适应这两种业务形态，面临很大的挑战。为了应对这种挑战，Gartner 公司提出双模 IT（Bimodal IT）的理念：
- 模式 1：专注于可预测性，针对更可预测和更易于理解的领域进行了优化
- 模式 2：探索性的，尝试解决新问题并针对不确定领域进行优化
传统企业数字化转型的常规做法是可预见性的业务使用传统瀑布式开发，称之为稳态；探索性的业务使用敏捷开发，称之为敏态。Thoughtworks 洞见安辉的文章《敏捷转型中的敏态与稳态》对此有比较详细的介绍。
当然，稳态和敏态的这种做法在业界也存在争议。Thoughtworks 数字化专家肖然在文章《数字化时代的科技双模，双模 IT 成为过去式》中指出：
- Gartner 的双模 IT 并非对应于瀑布和敏捷两种开发模式，整个 IT 组织走向敏捷是数字化时代的必然。
- 双模 IT 的提法确实已经不再适合于现代数字化业务的打造，问题不在“双模”，而在于将 IT 作为整个科技转型的出发点。
- 数字化转型的核心是需要科技真正融入业务，成为业务发展的核心动力；需要从客户视角去洞察需求，用科技的手段创造未来，单方面聚焦传统意义上的业务或者技术都是南辕北辙的。
尽管如此，传统企业转型过程中，基本都会长期经历敏态和稳态共存的阶段，对转型有着积极的意义。从长远来看，最终还是需要转型到组织级的敏捷，实现真正的全流程端到端敏捷。
2. 敏捷测试
关于敏捷测试，引用 Wikipedia 的两段话：
Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. (敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。敏捷测试涉及跨职能敏捷团队的所有成员，由测试人员贡献特殊专业知识，以确保以可持续的速度频繁地交付客户所需的业务价值。)
Agile development recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile teams use a "whole-team" approach to "baking quality in" to the software product.(敏捷开发认识到测试不是一个单独的阶段，而是软件开发的一个组成部分，与编码一起。敏捷团队使用“整个团队”的方法来将质量“烘焙”到软件产品中。)
从 Wikipedia 的定义可以看到：
- 敏捷测试不是针对测试人员，而是整个敏捷团队的所有人员；
- 敏捷测试不是指测试这个独立的环节/阶段，而是跟编码一起同属于软件开发的一部分；
- 敏捷测试不是通过测试验证去保障质量，而是强调质量内建。
同时，Thoughtworks 的资深 QA 们基于多年敏捷团队开发实践经验提炼出的《敏捷测试宣言》，非常清晰的表述了敏捷测试的价值观：
敏捷测试是基于敏捷价值观“快速高效地交付更大的价值”这个目标，所开展的所有质量相关活动，是从团队的角度去思考如何实现这个目标，而不再是以测试这个活动/角色的角度出发，不能简单地理解为“敏捷的测试”或“敏捷地测试”。
关于敏捷测试的更多详细内容，欢迎参考刘冉老师的《Thoughtworks 的敏捷测试》文章和我的《敏捷测试》系列 文章。
3. 测试敏捷化
测试敏捷化这个概念来自于双态 IT 联盟发布的《测试敏捷化白皮书》（以下简称“白皮书”），这里直接引用该白皮书中的内容来解释测试敏捷化。
(以下粉色背景斜体部分引用段落全部来自白皮书原文）
测试敏捷化是指在与软件生命周期所有交付品质相关的活动中，通过对组织、文化、流程、技术等要素进行优化与改进，使得测试能够贯穿于研发全过程并与上下游团队高效协作；能够在业务与技术水平上持续提升，达到自我驱动、灵活赋能、快速交付、高效稳定的最终目标。
测试敏捷化这个概念第一次在业界提出，强调测试应作为一个赋能主体，具备全局眼光，通盘思考通过测试敏捷化赋能的方式为快速迭代、持续交付过程提供支撑。
测试敏捷化提出本质是跳出被动测试思维，更加关注测试真正的价值。测试不仅是完成被分配的测试任务，而更应该看到测试可以作为独立主体为研发一体化赋能，以此实践和推动 IT 组织的敏捷化。
测试敏捷化，即未来测试应考虑如何独立地构建自身能力，以赋能为手段对外部输出，提供安全、稳定的质量和效率服务。
从前面引用的内容来看，测试敏捷化是将测试作为独立主体，从测试的角度出发来考虑优化和改进。
基于白皮书的内容，双态 IT 联盟发布了相应的成熟度评估模型，这个成熟度评估也是基于测试的几个维度进行的：
到此，我们可以比较清晰地看到测试敏捷化是围绕测试在解决问题，考虑的更多是测试价值的体现。
02 测试敏捷化 VS 敏捷测试
了解了概念，再来从背景、目标、主体、关注点和适用范围这几个维度集中对比一下测试敏捷化与敏捷测试：
从上表我们不难看出测试敏捷化与敏捷测试具备较大差异：
1. 背景与目标
敏捷测试是产生于敏捷软件开发模式，在这种新型开发模式下需要考虑如何满足质量保障的需求，自然而然产生了敏捷测试。敏捷测试是遵循敏捷价值观的，其目标也是跟敏捷开发一致，那就是快速高效地交付更大的价值。
测试敏捷化则是在数字化转型过程中敏稳两态共存的情形下，传统 IT 稳态模式的测试团队面临转型挑战，旨在帮助测试团队实现转型。因此，测试敏捷化的目标主要是为了体现测试的价值，提升测试团队的敏捷能力。
2. 主体与关注点
为了实现目标，敏捷测试以全功能的敏捷开发团队为主体，关注软件开发全生命周期的质量相关活动。敏捷测试不再是以测试这个检验环节/活动为主，不会强调某个独立角色，而是要求团队整体为质量负责，实现测试左移、持续测试和测试右移，快速获取反馈，从而真正实现软件产品的质量内建。
而测试敏捷化是以测试作为独立主体，以测试的角度出发考虑优化改进，主要关注点包括测试需求、测试计划、测试设计、测试执行等测试过程，以及环境、数据、技术、工具等测试的支撑。
3. 适用范围
如上面数字化转型示意图所示：
敏捷测试产生于敏捷开发模式，必然适用于纯敏态的开发团队。同时，敏捷测试的一些方法和实践，也可以被稳态团队所借鉴并适当采用。
测试敏捷化由于背景、目标、主体和关注点都不同于敏捷测试，是不宜用于敏态开发环境的，只适用于稳态环境。
03 测试转型的正确方向
数字化转型的确给传统测试团队带来很大的挑战，一方面要配合敏态团队实现测试开发融合，另一方面还要面临稳态测试如何优化改进的问题。
测试敏捷化虽然在一定程度上帮助转型中的稳态测试团队，但是不能从根本上帮助转型的实现。另外，前面提到敏稳双态共存模式不过是转型中的一个过渡阶段，是否要为这种过渡时期的稳态模式投入较多精力，请深思而前行。
测试要实现转型以适应敏捷开发模式，不能只是测试人员的转型、也不能只是测试工作方式的转型，只有改变文化理念和认知方式、调整组织架构和沟通方式、优化流程和策略、采用有利于快速反馈的工具与实践，按照由内而外的“道”->“法”->“术”->“器”方向实现彻底的转型，才有可能实现真正的敏捷测试。
04 写在最后
敏捷测试不是“敏捷的测试”，也不是“敏捷地测试”，而测试敏捷化是“敏捷地测试”，两者不等同。
测试敏捷化的背景、目标、主体和关注点都不同于敏捷测试，是不宜用于敏捷开发模式的，只适用于传统企业的稳态模式，也不能帮助稳态团队实现敏捷转型。而敏态、稳态共存本身就是数字化转型的过渡阶段的产物，因此在稳态测试团队采用也需要谨慎前行。
传统测试的真正敏捷转型需要遵循“道”->“法”->“术”->“器”方向、实现由内而外的转变才能实现。
