软件质量文化：谷歌实践及我的思考
阿里QA导读：软件质量文化是一个重要但是探讨不多的话题，让我们跟随着这篇文章，看看何为软件质量文化
0 缘起
前段时间，一篇题为《谷歌资深工程师讲述谷歌如何思考测试》的博文在国内测试圈广泛流传，引起了我的关注。我特意去调查了一下这篇文章的背景，发现它其实是新书《谷歌软件工程》(2022)的一个章节，于是果断下单了一本。当拿到这本书时，我不禁想起以前买过的另一本书，2013年由3位阿里测试前辈翻译出版、至今仍在测试圈产生广泛影响的《谷歌软件测试之道》。
图1：两本间隔十年的书
这两本书出版的时间差不多间隔十年。在把这两本书摆在一起时，我产生了强烈的好奇：过去十年，不管商业领域、技术领域还是测试领域都发生了很大的变化。那么，对于谷歌测试，尤其是它最核心的测试文化来说，变与不变的地方在哪里？背后的原因是什么？对我们有什么启示？
时间最好的试金石。是的，十年是一个足够长的时间跨度。一件错误的事情，很难坚持十年(而不被众人发现、挑战、抛弃)；能坚持十年的事情，大概率是正确的事情(能产生长期价值)。这篇文章，就是我在阅读上述2本书之后，并结合自己8年的软件测试职业经历和5年的软件测试公众号运营经历，对于软件测试文化(或质量文化，两个词语含义有些差异，但在本文范围内等价)这个我认为很重要(它是很多问题的根)但国内测试圈探讨并不多的话题，所产生的心得体会。今天分享给大家，欢迎对软件质量文化感兴趣的朋友们一起交流、指正。
1 谷歌这十年
尽管谷歌是个家喻户晓的公司，但是我觉得在进入正文之前，还是有必要简要介绍一下谷歌的基本情况，尤其是过去十年的发展情况。谷歌成立于1998年，已有25年历史。由于宏观经济与市场环境的影响，用市值或股价来衡量一家公司不是一个好主意。但是巴菲特说过，股市短期是投票器，长期是称重机。谷歌2004年上市至今，20年来市值增长40倍，截止目前总市值1.36万亿美金，位列硅谷科技公司第3名，仅次于苹果和微软。
图2：谷歌上市20年来市值变化曲线图
谷歌不仅打造了搜索、Gmail、YouTube、谷歌Earth等100+优秀的商业产品，服务了全球43亿用户，而且它创造的技术产品也是如雷贯耳，包括操作系统Android、前端编程框架Angular、编译系统Bazel、跨端开发框架Flutter、后端编程语言Go、机器学习框架TensorFlow等。
图3：谷歌核心商业与技术产品一览
在快速变化的互联网领域，谷歌早已不是一家年轻的公司。然而，有趣的是，谷歌成长的速度并没有随着规模的增长而变慢。例如，从市值观察，谷歌上市后第1个十年市值增长6～7倍，第2个十年市值也是增长6～7倍。“大象在起舞，巨人在成长”。谷歌的成功，毫无疑问跟它的企业文化尤其是软件工程文化有很大关系。那么作为谷歌工程文化的组成部分(根据上述两本书的描述，测试文化事实上是谷歌工程文化的核心)，谷歌的测试文化究竟是一种什么样的存在？在过去的十年，它变和不变的地方是什么？
2 一个持续17年的活动
说到谷歌代表性的测试文化，不能不提的一张名片就是“Testing on the toilet”，即“马桶上的测试”。这是谷歌公司早期一群对软件测试抱有极大热情的志愿者(内部称为测试小分队，Testing Grouplet)发起的，一个旨在宣传、鼓励和帮助谷歌工程师(主要是开发工程师)更好开展测试的文化活动。活动创始于2006年，当年曾经作为新闻被华盛顿邮报报道，引起社会的关注。如今，外界早已不再关心这件事情，但是它仍然在谷歌公司运行，迄今已走过17年的历程。
什么是“马桶上的测试”？它是一张不定期更新的海报，张贴在谷歌全球各个办公区卫生间的马桶旁边。海报内容从测试理念、方法、技术、工具、实践，到测试的上下游工作，包括静态分析、代码评审、代码覆盖等，可以说囊括了软件测试与质量的方方面面，并且内容生动、引人关注。
在测试小分队的先驱们看来，卫生间是工程师们每天至少要去一次的地方，并且上卫生间的这段时间，工程师的注意力更容易被捕捉。因此，在卫生间张贴的海报，成为一个宣传测试的绝佳场所，能够最大程度上实现对目标读者的有效覆盖。“马桶上的测试”海报，从最初的志愿者编写到后来的谷歌工程师主动投稿，成功地从一个想法变成了持续17年的活动。在潜移默化中，它改变了谷歌的测试氛围，影响了几代谷歌工程师，成为谷歌测试文化历久弥新的最好见证。同时，这个活动也在业界产生影响，被其他科技公司纷纷效仿。
图4：马桶上的宣传 (a) 谷歌测试海报 (b) 阿里“卓越工程”小贴士
3 质量变革的核心抓手
谷歌测试小分队的先驱们很早就意识到一个常识：软件质量只能内建，不能外加(注意这不意味着不需要测试，毕竟若不经过测试，如何证明软件有质量)。因此，他们确定了努力方向，通过让开发工程师承担主要的测试工作(而不是增加测试工程师的数量)来提升软件质量。不管在认知层面还是在组织层面，这都堪称是一场革命，其推进难度之大、阻力之巨可想而知。仅靠“马桶上的测试”海报对于测试文化的宣扬，显然不足以支撑这一目标的达成。
如果说海报只是激发开发工程师开展测试的想法，那么当他们真正想要进行测试时，其需要的是一套可执行的操作指南。在谷歌，“测试认证”(Test Certified)项目，承担的就是这个职责。是的，就是这个名字很不起眼的项目，帮助了谷歌内部无数产品和项目改善了质量。与“马桶上的测试”一样，“测试认证”同样持续了十几年时间，成为谷歌测试文化的一部分。
什么是“测试认证”项目呢？概括地说，它定义了一套度量项目测试成熟度的标准，并且更重要的是，提供了测试成熟度从低等级往高等级跃迁的操作指导。注意到，“测试项目”有着明确的度量标准，这看起来似乎是一件非常适合借助管理层行政命令在各个研发团队强制推动落地的事情。
的确，项目的发起人(即测试小分队的先驱们)一开始也有这样的想法，毕竟这样做可以在短期内快速落地、看到结果。然而，在经过深思熟虑后，他们主动放弃了这样的想法。他们意识到，这样的想法不仅与谷歌的企业文化不匹配，而且更重要的是，不利于“测试认证”项目的长期成功。强迫工程师做测试，这不是一件可持续的事情。如果工程师真正接受了这个想法，他们会自己决定要做测试，即使在没有人强迫或监督他们的情况下，也能继续做正确的事。
项目发起人相信，好的想法会被接受，成功的故事会传播，因此重点在于展示成功。于是他们采取了很多动作，包括：选择测试意识较高的团队优先试点、全程的教练支持、及时的鼓励和赞美、降低入门等级的达成门槛(先入门再提高)、趣味性十足的宣传等。事实证明，“测试认证”项目的发起人当初的决定是正确的。这个项目在没有行政命令推动下，通过项目成员的努力，从“星星之火”渐成“燎原之势”，累计促成1500多个产品团队接入该项目并从中受益。
这里，附上谷歌“测试认证”项目对测试成熟度的5级模型定义，仅供参考。
图5：谷歌“测试认证”项目关于测试成熟度的5层定义
注意到，最近谷歌内部将“测试认证”升级成了“项目健康度量”，关注的指标从项目质量扩展到了项目健康度，内涵更丰富。
4 对尺度保持警惕
在测试领域，测试金字塔理论几乎无人不知。根据金字塔理论，软件测试被划分为单元测试、集成测试和系统测试等有着不同目的和特点的类型。金字塔模型认为：不同类型测试用例的大致比例应该符合金字塔结构，即最底层的单元测试占比最多，中间的集成测试其次，最上层的系统测试最少。与测试金字塔模型形成对立的，有冰淇淋模型、沙漏模型、纺锤模型、奖杯模型等。
图6：各种测试分层模型对比
测试金字塔理论建立在软件测试的一个基本常识之上：BUG发现得越早，其解决的成本越低。因此，我们应该将测试资源尽可能地向软件开发的早期阶段倾斜。金字塔的本质，是在不同特点的测试类型之间寻找一个平衡，目的是用尽可能低的成本达成尽可能高的质量。
与大部分公司一样，金字塔模型同样是指导谷歌大部分测试工作的黄金法则。所不同的是，谷歌的表达方式略有差异。在谷歌，使用小型测试、中型测试和大型测试来分别描述一般意义上的单元测试、集成测试和系统测试。我们知道，单元测试、集成测试和系统测试作为完全不同的测试类型，其差异之处是方方面面的，而用例的尺度只是众多差异之一。
图7：三种类型(小型测试、中型测试和大型测试)测试的全面对比
为什么谷歌特别强调用例尺度这个差异，有其深刻背景。作为谷歌特色的金字塔模型，其在强调用例分布比例的同时(作为指导原则，一个项目的测试用例由80%的小型测试 + 15%的中型测试 + 5%的大型测试组成)，对扩大用例尺度的行为保持警惕。换句话说，它总是鼓励工程师尽可能地缩小用例尺度，编写范围较小的测试。从短期来看，端到端的大型测试用例，无疑更能证明软件是否工作，从而达到立竿见影的测试效果。但是，大型测试用例在执行效率、维护成本、稳定性等方面的固有劣势，对于长期测试结果与质量目标的达成是不利的。
关于测试金字塔，谷歌的另外一个特别之处是：谷歌的测试金字塔基本等同于自动化金字塔(谷歌总是尽可能地将每个测试用例自动化)，并且，绝大多数自动化用例(如果不是全部的话)是由开发工程师编写和维护的。
开发工程师驱动的自动化测试，是谷歌测试文化的核心内容。
5 创新不止
在谷歌，开发者驱动的自动化测试早已与软件开发流程深度融合在一起。从代码提交前、提交后到发布前，在开发流程的各个关键节点，海量自动化测试不知疲倦地运行着。
由于谷歌采取的是单一代码仓和主干开发模式，成熟的自动化覆盖叠加海量的自动化执行，所构成的“谷歌规模”的自动化测试，面临着史无前例的技术挑战，包括：1) 效率挑战：开发工程师的时间是非常贵的，自动化测试如何在尽可能短的时间内给予工程师质量结果反馈？2) 稳定性挑战：自动化规模扩大时，用例不稳定性(Test Flakiness)成为挥之不去的噩梦，如何克服或减轻不稳定性用例的影响？3) 有效性挑战：自动化用例是否能够真正覆盖逻辑、检测缺陷，发挥它应该发挥的价值？
这里，用几个简单的数据，说明“谷歌规模”的自动化测试复杂度有多高：2.5w名开发工作在同一代码库，每天产生4w次代码提交，改动一个文件最多要执行420w个测试用例，总共556w个用例中有4.7w个不稳定用例。为了克服这些挑战，谷歌进行了大量技术创新。过去十年，谷歌在软件工程学科的顶级会议/期刊上，发表的关于软件质量的部分高引用论文如下：
图8：谷歌过去十年在测试领域发表的高引论文列表(部分)
面向大规模自动化测试效率、稳定性、有效性的技术创新研究，也是谷歌测试文化的一部分。
6 那些离开的先驱们
“马桶上的测试”、“测试认证”、开发工程师驱动的自动化测试金字塔、浓郁的测试技术创新氛围，共同构成了谷歌测试文化的核心。当然，这些不是谷歌测试文化的全部，其他测试文化还有：面向谷歌新员工的测试培训课程、从2007年至今更新不断(尽管更新频率显著降低)的谷歌测试博客(https://testing.googleblog.com)等。
谷歌测试文化的传承和延续，与每一个谷歌工程师的坚持与努力密不可分。但是，“饮水思源”，那些发起“马桶上的测试”、“测试认证”等文化活动，至今仍然深刻影响每一个谷歌工程师的测试小分队的先驱们，是应当被大家认识和铭记的。为此，我调研了一下谷歌早期测试先驱们的近况，结果发现他们大部分都已经离开了谷歌。
图9：那些离开谷歌的测试先驱们
这些离开谷歌的测试先驱们，很多都去了硅谷其他的科技公司，并且将谷歌的测试经验和文化带了过去。从某种程度上可以说，他们将谷歌测试文化发扬光大，形成了硅谷测试文化。测试小分队早期核心人物Mike Bland在离开谷歌时，在个人博客中骄傲地写道：我们改变了这家改变世界的公司。We changed the company that changed the world。他后来加入了苹果公司。在苹果，他组织和发起了苹果质量文化倡议(Apple Quality Culture Initiative，Apple QCI)活动，改变了苹果的软件质量文化。
图10：大同小异的谷歌质量文化与苹果质量文化
7 测试职业变革
谷歌测试文化的巨大变革，在繁荣开发者测试的同时，也给测试工程师的职业发展带来了很大的冲击。在谷歌，名称中带有“测试”的岗位有两种：测试开发工程师(Software Engineer in Test, SET)和测试工程师(Test Engineer, TE)。随着开发工程师逐渐承担主要甚至全部的测试工作，以及DevOps、CI/CD、灰度发布、众包等软件开发与交付模式的变革，SET和TE的工作职责也在不可避免地发生变化。
SET不再负责功能/产品相关的自动化用例的开发，而是聚焦在自动化测试工具和研发基础设施的开发。SET和测试的关系越来越小，本质上成为了开发工程师。SET不仅开发测试工具，而且也开发所有推动软件工程生产效率提升的生产力工具。显然，SET的职位名称已经过时了。2016年，谷歌针对所有SET发起了一项调查，让他们选择一个新的岗位名称。结果有91%的SET选择了新的名称：Software Engineer, Tools & Infrastructure，SETI。“Testing”不复存在。
TE的工作则慢慢脱离具体的测试设计和执行，而变成了专家型或者管理型的角色。就像《COOL to be a TE @ Google，2020》一文中总结的，谷歌测试工程师的核心特质变成了4点：持续的学习者(Constant learner)，打破常规的思考者(Out-of-box thinker)，编排者(Orchestrator)和前沿的用户(Leading-edge user)。一方面，作为专家角色，测试工程师与开发工程师密切协作，制定测试策略、识别和解决可测性挑战。另一方面，作为组织者角色，测试工程师通过管理和驱动内部用户、外包测试、众包测试、早期尝鲜用户等低成本的测试资源来完成测试工作。
作为专家或者组织者的测试工程师，显然不再需要保持以前那样的数量了。SET和TE职业岗位的变迁，是以“开发者驱动的测试”为核心的质量文化在谷歌落地生根、枝繁叶茂的自然结果。
8 在争议中前行
即使是通过激发内在兴趣而不是采取强制命令驱动开发工程师做测试，在谷歌质量文化落地的过程中，各种争议仍然无处不在、甚至至今还在延续。
微观层面的争议，既有：“我没有时间做测试”、“写测试会让我的开发速度变慢”、“我想写测试但是组织是否认可写测试的价值”、“我的代码很难进行测试”、“测试代码对用户不可见，为什么要投入时间去写”，也有：“100%的代码覆盖率不能说明代码没有问题，为什么还要提升代码覆盖率”、“既然我写再多测试也不能避免不发生问题，那我还要写更多测试吗”？
宏观层面的争议，既有：“考虑自动化测试的维护成本，ROI值吗？”、“测试需要做到什么程度，产品质量才能好？”，也有：“加强质量工作，是否意味着更高的成本投入？”、“加强质量工作，是否会让团队交付效率变慢？”。
类似的争议，不仅在谷歌存在，在其他公司也是存在的。关于测试或质量工作，之所以会存在这么多的争议，与软件质量的一些特质有关：质量可见性不足、没有完美的质量、质量好坏缺乏一致的度量、质量投入和结果显现的长期性。对于种种争议，谷歌的测试先驱们的态度是：坦然面对争议，但是坚持“质量是一件正确的事情”的基本价值判断。既然是正确的事情，应该做的事情，那么做就行了。
9 Where we are
至此，本文介绍了谷歌的质量文化是什么样的，怎么建立质量文化，以及过去十年谷歌质量文化的变化。可以说，谷歌的质量文化基本上代表了硅谷的质量文化。公开的资料显示，亚马逊、苹果、Facebook等科技公司，其质量文化与谷歌是类似的。即使是曾经作为传统测试文化代表的微软公司，也已经针对测试进行了重大变革，越来越向谷歌模式靠近。当然，微软在转型过程发生了诸如win10质量下滑这样的负向事件。但是，转型的趋势已不可逆转。
坦白说，我自己并没有在硅谷工作过，了解到的关于谷歌或者硅谷测试的一切，都是来源于公开资料。尽管如此，根据自己8年的测试职业经历和5年的测试技术公众号运营经历，以及与很多测试同行直接或者间接的交流，整体感受是：国内测试也在受到硅谷测试文化的影响。一个大的趋势是，开发工程师越来越多地承担测试工作，而测试工程师的职业发展则面临着挑战。不同公司、不同产品、不同团队，变革的节奏有差异，但是变革的方向趋于一致。
客观来说，由于测试是上下文依赖的(软件测试的基本原则之一)，就像世界上没有两片相同的树叶，世界上没有两个产品能够采取完全相同的测试策略。积极的一面是，我们看到测试团队紧贴业务实际，建设了符合业务特点和发展现状的质量保障体系、能力和工具，贡献了测试人应该贡献的价值。
在我所经历的每个测试团队，不管是通信、云计算还是电商行业，不管测开比是1:3、1:10还是1:30，不管是中心化的质量团队还是分散到业务的质量小团队。大家都在客观条件(包括管理层对质量的重视度、开发的质量意识、测试资源、项目交付压力)的约束下，围绕以更高效率、更低成本发现更多BUG的目标，努力工作。
但是，当大家希望软件质量发生根本性好转(多数情况)、或者让质量水平更上一层楼(少数情况)的时候，都会面临着一个共同的挑战，那就是怎样推动质量左移，从源头上把质量做好。要攻克这个挑战，测试工程师思考的问题，需要从“术”的层面，上升到“道”的层面。
因为，我们要解决的不再是测试策略、测试能力、测试工具的问题，而是测试文化的问题。
10 文化是根本
最近我在思考一个问题，如果接手一个自己完全不熟悉的业务，该如何建设相应的质量工程体系？业务的不同，必然会带来保障体系的差异化。但是，从宏观层面看，面向不同业务的质量工程体系应当有一个通用的框架。于是，我产生了质量金字塔(Quality Pyramid，区别于测试金字塔 Test Pyramid)的构想，其由3层(1+2+3)组成。
图11：质量金字塔示意图
最上层：生产质量，包含稳定性、安全生产、用户体验相关工作；这是质量领域可见度最高的工作。任何线上问题都可能引发广泛关注；一个严重线上故障，甚至可能引发新闻舆情，对产品甚至公司未来产生重大影响。
中间层：这一层是为了尽可能避免(无法绝对避免)线上问题发生，这也是测试的中心目的。它由2部分组成：开发工程师驱动的质量内建和测试工程师驱动的质量防护网。绝大部分质量问题应该在质量内建阶段发现和解决，质量防护网致力于发现那些在质量内建阶段难以发现的问题。注意到，中间层工作涉及测试与开发两个工种的深度协同。
最底层：质量流程、质量工具、质量文化，3部分共同构成质量工作的基石。质量流程相对容易建立，只要流程各方达成一致、按照规则执行就行了。质量工具有开源产品可以利用，即使要自研，投入资源短期内也能搞定。唯独质量文化的建立与坚持，非一朝一夕之功。
毕竟，质量文化不是孤立的，而是工程文化、企业文化的一部分。谈到质量文化，我不禁想起贵州茅台公司著名的“四个服从”：当产量与质量发生矛盾时，产量服从质量；当成本与质量发生矛盾时，成本服从质量；当效益与质量发生矛盾时，效益服从质量；当速度与质量发生矛盾时，速度服从质量。
茅台酒做的百年生意，它对质量文化的要求果然不一般。相反，如果一个公司做的是“昙花一现”的生意、开发的是“没有生命力”的产品，那么谈论质量文化，或者说投入资源去搞质量工作，又有什么意义？
因此，我们建设质量文化有一个大的前提：质量攸关产品的前途命运、大家对高质量愿景有共识。
11 结语
软件测试从来都不是一件在聚光灯下的工作，但是它对产品有益，对用户有益，是一件正确的事情。感谢谷歌为我们探索了一条“把软件测试这件正确的事情做正确”的有效路径。路径的核心不是惊世骇俗的测试理论、炫酷的测试工具、让人膜拜的测试论文，而是卓越的、可持续的、工程师自驱的软件质量文化。
最后，以一句话结束本文。
打造经过几代工程师仍然屹立不倒的质量文化，是质量领域最难的工作，值得每一个测试人为之努力。
与大家共勉！
参考资料：《谷歌软件测试之道，2013》，《谷歌软件工程， 2022》，谷歌测试博客testing.googleblog.com等。
关注「阿里巴巴技术质量」阅读更多