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