https://insights.thoughtworks.cn/quality-assurance-enablement-in-agile-team/
“没有专职的测试人员？
代码提交就直接发布到生产环境？
而且，一天还可以发布多次？”
对于很多团队来说，这是完全不可能的事情！他们都是怎么做到的？
相信很多人都对前面这些问题很好奇，在解开谜团之前，我们先来看两个案例。
案例1
随着互联网业务的发展，某行业核心系统为了面对互联网的挑战，需要对系统进行改造。可是，真想改起来却寸步难行……
该系统已经有十多年的历史，业务规则复杂，业务逻辑代码全部都在数据库脚本层；缺乏有效的业务文档，需求分析文档是以系统页面流转和操作步骤为主的形式，开发和测试人员对业务没有清晰的概念，只是知道系统有哪些操作，某个操作对应的真实业务并不清楚。
面对几百万行代码的改造，没有业务上下文的支撑，其难度可想而知。
案例2
某团队开发半年的一个网站在上线前一个多月发现根本没法正常运行，被迫延期半年后才上线……
原来，该网站是基于一个第三方平台开发，由于业务的特殊性需要支持2TB的数据量。但是，该第三方平台并没有验证过可以支持这么大的数据量，在上线前一个多月UAT环境准备就绪，系统在UAT运行的时候完全垮掉。
在进退两难的情况下，团队也只有硬着头皮往前走，一边优化自己开发的程序的性能，一边还要协助第三方平台进行升级……团队所经历的种种心酸也是不言而喻。
前面两个案例的痛我们都能感觉到，那么问题到底出在哪里？
案例1：寸步难行的遗留系统
案例2：延期半年才成功上线的网站
在传统的质量保障模式下，前面案例所发生的事情并不少见。随着业务和技术的不断发展，对传统系统的质量之痛，相信大家都是深有体会。
一方面，靠独立的测试团队把关质量，靠滞后的测试阶段来测试、发现系统的问题，导致大量时间的浪费和成本的升高。
另一方面，不同角色的人员相互独立、甚至有着高高的部门壁垒，是一种相对对立而不是合作的关系。普遍认为测试是最终要对质量把关和负责的，其他角色各自做好自己阶段范围内的工作就好，形成了一种“各人自扫门前雪”的局面，而没人能将业务需求到产品整个串起来，确保是否开发了正确的系统。
这样的质量保障方式已经不能适应今天的发展，需要团队整体对质量负责。要让习惯了“自扫门前雪”的团队不同角色都能做到为质量负责，不是喊喊口号就可以做到的。因此，如何对团队进行质量保障赋能成为搞好质量的关键。
开篇提到的那几个问题说的就是前沿的互联网科技公司Google、Amazon和Facebook等，他们都是质量保障赋能做的非常好的典范。
通过对那些大公司的软件交付实践进行调研分析，不难得出以下几个方面的共性：
全流程标准化，从字面意思就可以理解，指的就是严格设定整个软件开发流程，流程上每个环节的具体做法都有标准的定义。更进一步，可以理解为两个方面的内容：标准流程和标准实践。
标准流程
流程可能包括需求计划、代码审查、静态扫描、动态测试、部署发布、监控等，流程标准化就是定义清楚流程中都有哪些环节。
为了保证流程的标准化，最常见的做法就是采用流水线，以及流水线上的标准工具来实现。
然而，工具并不能独自保障标准化的实施，有些环节还需要结合规则或者政策进行一定的约束来做到，如代码提交规则、测试覆盖率的要求、失败回滚政策、发布的规则等。
标准实践
标准流程之外，一些标准的实践也属于全流程标准化的一部分。当然，在标准流程各个环节所采用的也都是标准实践，这里单独列出只是想进一步强调标准实践的重要性。流程外的标准实践主要是针对标准流程以外的一些特定领域或者特定场景下的实践，像针对安全领域的威胁建模、针对微服务架构带来的不确定性的混沌工程等。
事实标准与书面标准
说到标准化，可能有人会说：“我们也在做标准化，也有指标和规则要求，比如有持续集成流水线，要求做代码评审，要求单元测试覆盖率不能低于多少，要求用户故事的开发速度一个点两天完成等等，可是我们还是做不到一天多次发布……”
这似乎是我们见得很多的标准化，这种标准化更多的是停留在书面的一些指标要求，而具体怎么实现指标其实有很多的方式……
比如：
这样的结果是表面看起来指标都很漂亮，而质量却令人堪忧。这是一种书面标准，很难真正做到质量保障赋能。
前面分析的Google、Amazon和Facebook除了有书面的指标要求，更多的是规定了实现指标的路径，比如：各团队统一的代码仓库管理与严格的代码提交权限，各个环节规定统一工具的使用、统一的模板和政策，使得整个软件开发和交付流程只有一种选择，并且遵循这些规则和路径一定可以实现指标的要求。
这是一种事实标准，比书面标准能够更好的做到质量保障赋能。
说到自动化，大家很容易想到了自动化测试。其实，这里说的大规模自动化，不仅有大规模的测试自动化，还包括大规模的流程自动化。
测试自动化
自动化测试当然是跟流水线和标准化分不开的，通常流水线上自动化测试不仅有动态的测试脚本执行，也有静态的自动代码扫描。
流程自动化
测试自动化主要是用来验证系统是否按照预期在运行，保证的是软件系统的质量。而流程自动化是保障流程更高效、更正确执行的非常重要的手段。
另一个共性是所有权制度，这是一种可以激励员工内在动力去主动承担质量保障职责的方式。就好比父母会对自己的孩子负责那样，代码、服务、产品所有者也会比较容易积极主动的去对自己所有的代码、服务、产品这些个“孩子”负责。
然而，任何实践都有两面性，用的不好可能带来坏的结果。所有权制度也可能导致跟我们提倡的“团队共同承担质量保障职责”产生矛盾，形成不同的利益群体，真正遇到问题的时候发生“踢皮球”现象。因此，所有权实践也是需要小心谨慎的，注意评估、持续改进很重要，也可以由小团队共同承担所有权职责的方式，或者不同的人或团队轮流承担所有权职责。
标准化和自动化相辅相成，标准化做的好就能更方便的实现自动化，而自动化又是有助于标准化实现的手段。
全面的标准化和自动化使得犯错几率降低，加快了软件交付速度，但同时也可能影响技术人员的能力提升。因此，需要鼓励团队创新，将经验教训固化为新的规则政策，创建新的和优化已有的标准。这些流程实践并不是一成不变的，而是不断演进完善的。
鼓励创新是公司提供的文化氛围，是一种外在的激励因素，而所有权制度是可以激励员工内在动力的方式。
所有权制度也可能带来负面的效果，不仅需要时刻回顾和改进，还务必跟标准化和自动化结合起来，以形成有机整体，尽量减少任何一个实践带来的负面影响。
因此，标准化、自动化和所有权三者有机结合，是质量保障赋能成功的关键。
标准化、自动化做的那么好的，那都是别人家的公司。而我们大多数的公司或团队，由于企业文化、组织架构、思维习惯、人员能力、基础设施等因素的影响，要做好质量保障赋能非常地难。
做不到别人家的公司那样，我们在除了尽力做到标准化和自动化之外，还能做些什么？下面分享我和同事在Thoughtworks经历的一些实践。
“全程的测试介入”是被我们写进敏捷测试宣言的一条价值观，测试左移、持续测试和测试右移都是价值观具体的体现。
从赋能的角度来看，敏捷开发团队的QA全流程介入，参与多个环节，承担赋能者的职责，起到帮助团队做好质量保障赋能的作用，具体的实践可以总结为以下三个方面的内容。
模板或清单（Template/Checklist）
QA跟不同角色共同制定一系列的模板或者清单，以帮助该角色更清晰的了解到所处环节需要考虑或者完成的事情。这些模板或清单可能是：
结对或评审（Pair/Review）
QA通过与不同角色的结对，可以把测试技能和对质量的关注意识传递给其他角色，以提高整个团队的整体质量意识。
跟不同角色的结对实践可以有：跟BA结拆分用户故事和编写验收条件，跟开发结对拆分任务、实现端到端自动化测试，跟运维结对设定线上监控与分析等。
除了结对，QA还可以通过评审的方式传递质量意识，比如用户故事、单元测试、日志记录情况的评审等。
质量主题分享或工作坊
QA可以定期跟团队分享质量保障内容，也可以邀请不同角色的同事一起来分享，这些内容可以是：质量保障小知识、项目测试策略与计划、项目质量状态与风险、一些典型bug的发现过程或者诊断定位过程。
除了独立的分享以外，还可以通过工作坊的形式邀请团队成员深度参与体验，比如：头脑风暴测试方案、缺陷根因的深度分析、bug大扫除（bug bash）、生产环境支持策略和流程的改进等。
这样的两种方式，一方面有助于帮助团队普及质量知识和提高质量意识，另一方面让团队不同角色对质量有更深的体会、更强的参与感，从而也就有了更大的责任感，起到赋能的效果。
交付业务价值是软件开发的根本目的，如果没能清晰理解业务价值，在开发过程中跟业务价值有偏离，将会带来很大的浪费。虽然大家都知道业务价值的重要性，然而业务价值要让整个团队都能很清晰的理解，并不是一件容易的事情。
我们特别强调业务价值驱动测试，所采取的业务价值驱动的测试实践，有助于将业务价值传递给整个团队，让业务价值跟系统实现和测试紧密关联起来。
关于业务价值驱动测试的更多内容，可以参考我之前的文章《业务价值驱动的测试》。
传递业务价值是正向的帮助团队开发正确的软件，而缺陷分析是通过对出现的问题进行详尽的根因分析、反向帮助团队改进的一种实践。失败是成功之母，缺陷分析的重要性和价值不难理解。
缺陷分析不是某个角色独有的职责，需要团队的共同参与，可以让团队不同角色对产品质量状态有更清晰的认识，这是一种有效的质量保障赋能实践。
关于缺陷分析的详情，可以参考我之前的文章《缺陷分析如何帮助质量内建》。
了解了团队质量保障赋能的各种实践，还有必要强调以下几个非常关键的必要条件。
要做好质量保障赋能，不仅需要质量目标驱动，很关键的一点是质量目标需要让团队每个人都清楚，并且需要定期回顾，持续调整。
每个阶段团队所有成员都需要清楚：
测试策略是质量保障的指南，为了让测试策略真正发挥价值，并且团队每个成员都能对测试策略有清晰的了解，我们推荐《一页纸测试策略》。
一页纸策略图只是策略的总览，背后需要大量的沟通和协作，更加有利于团队质量保障赋能，增强团队成员的质量意识。
前面说到了敏捷团队的QA需要承担起赋能者的职责，这需要QA上升到第三层，我的文章《再谈敏捷QA》有关于这三层的介绍。
QA只有从认知上做好转变，不再是简单测试人员的思维，才能更好的承担起这个艰巨的赋能任务。
从敏捷宣言和宣言所遵循的原则，可以总结出敏捷软件开发跟质量保障紧密相关的三点价值观：
前面分享的团队质量保障赋能系列实践，都是遵循的敏捷价值观，是适合敏捷团队的质量保障赋能。