大规模团队中的敏捷测试实践

1 介绍

随着全球、全产业数字化需求的进一步增加，越来越多传统行业和复杂业务都转向了数字化。要完成数字化转型，软件系统一般是必不可少的，但是对于很多传统行业中的复杂业务，都需要大型的软件系统。而大型的软件系统一般都是需要大规模的开发团队来进行开发。传统的瀑布模型看起来似乎非常适合大型项目的开发，但是随着软件危机的出现，软件研发专家提出了敏捷软件开发，用于应对模糊不清和不断变化的业务需求，尽早、快速和持续验证开发中的软件功能。

但敏捷开发的特性更适合于中小规模团队，而难以应对大规模团队。并且，敏捷开发中的测试实践，一般并不依赖独立的测试团队，QA 人员需要加入到交付团队进行工作，这也影响了敏捷测试在大规模团队中的实施，产生不少问题和痛点。解决这些问题和痛点的难度较高，如果第一次遇到，我们甚至会有点手足无措。我在曾经的大型项目中，或多或少遇到过这些问题和痛点，并且花了不少时间尝试分析和解决它们，甚至在一些特定的环境中根本无法解决部分问题，以至于浪费了不少时间。在这篇文章中，我总结了以下这些问题和痛点，希望能帮助更多的同学。

2 问题和痛点

首先我们定义下所谓的大规模团队，开发同一个软件系统，后台是一个，但是至少有 5 个以上不同又互相依赖的子系统或者领域微服务，前端应用可以是多个平台，并且拥有 5-20 个左右的独立开发组，每个组 8-20 人。这种规模的团队下就非常容易遇到不少特定的问题和痛点，并且我们将这些问题和痛点分为三类：流程，人员和技术。大规模团队和小规模团队最大的区别就是人多了，导致各种信息差的存在，这是最主要的根因。

2.1 流程

流程贯穿整个软件研发生命周期，涉及团队所有人员，所以基于它的问题和痛点相对最多。

2.1.1 谁以及如何设计出跨团队的基于产品的 User Journey Test？

这个是大型敏捷团队最为常见的一个问题。一般情况下，大型敏捷团队中都是划分独立的功能团队的，每个小团队都有自己的 BA，QA 和 Dev，他们一般情况下只知道自己开发的那部分功能和业务，从而导致没有人知道整体的业务的 QA 或者 BA。而整体的业务一般只有产品经理或者业务架构师知道。但是他们又太忙，也不太可能来编写测试用例。

这种情况下，一般有几种解决方案：选一些经验丰富的高级系统工程师，由他们组成一个系统工程组，由他们负责设计和编写；在每个功能团队中选取各自的 BA 和 PO，组成一个虚拟的团队，安排固定的时间让他们一起合作完成设计和编写；在项目开发的中后期，每个功能团队选出 1-2 个 QA，组成一个虚拟的系统测试组，安排固定时间让他们合作完成设计和编写。

方案 1 主要是适合于人力资源丰富且质量要求很高的软件系统，比如电信通信系统。方案 2 主要适合大型交付项目，编写的 User Journey Test 属于验收测试用例的一部分。方案 3 主要是在无法实施方案 1 和方案 2 的情况下的一个折中方案，一般不建议使用。

2.1.2 跨团队的集成测试如何有效开展？谁来主导或统一规划？

这个问题也是大型团队里面很常见的一个问题，原因和 2.1.1 的问题类似，主要是缺乏一个跨团队的团队。但是集成测试需要尽早展开，并且实施的主要是 Dev。其解决方案主要如下：首先项目需要一个整个项目的整体测试策略，并在测试策略中明确指出需要开展模块之间的集成测试。其次，模块之间的集成测试实践包括编写自动化集成测试，契约测试和 Schema 测试等。

2.1.3 整个项目的敏捷测试流程、测试策略的一致性如何保障？

越大的项目，人员变化越频繁的项目，不同的功能团队有着不同的 KPI 和 OKR 的项目这个问题上越痛。首先，项目越大，信息同步越难，信息传递失真越大。其次人员变化越频繁，信息也越难以给新来的以准确的传递。最后，很多大型项目的不同功能团队有着不同的 KPI 和 OKR，导致他们工作流程和工作方式和项目整体的策略是相冲突的，从而很多时候为了团队的 KPI 和 OKR 而有意无意的违背项目整体的测试。这个痛点是非常难以解决的，对于信息同步和传递的问题，需要建立起一套有效的信息同步和传递的机制，比如有效的文档和高效的会议模式，以及快速的反馈通道，让所有人都可以快速的反馈自己的问题，从而得到需要的信息。但是对于团队利益和项目利益冲突的问题，只有尝试互相妥协和退让，并尝试找到双赢的解决方案，不然一定是两败俱伤。局部最优还是全局最优，是一个永恒的难题，整体的最优解一定是双赢，但是双赢绝对不是对于某一方的最优解，所以如果某一方一定要追求自己的最优解，大概率都会损害另外一方的利益，从而大概率会导致整体利益的受损。

2.1.4 如何验证测试用例的有效性？如何验证测试结果的有效性？

大型项目中测试用例数量是巨大的，对于项目的质量管理者来讲，如此大量测试用例的有效性是非常难以验证的，并且由于编写测试用例的人员能力层次不齐，也很难保证测试用例的有效性。解决这个问题需要借用开发的一些方法和技术：使用类似结对编程和代码审查的方法，要求测试用例编写人员结对编写测试用例，或者编写测试用例之后需要另外一个 QA 或者 PO 来审查测试用例。使用变异测试（Mutation Test）这种技术手段来自动化验证自动化测试用例的有效性，但是它无法验证非自动化测试用例的有效性，这个也是它的局限。使用 BDD 和活文档这样的方法和技术，让测试用例可以更好的理解和呈现，从而降低测试用例理解和审查的难度。

2.1.5 不同团队的质量状态、质量风险如何同步共享给整个项目组/产品团队？

这个也是大型项目中常见的问题和难点之一，项目越大，复杂度越高，导致越难以度量质量状态和质量风险等。解决这个痛点最好的方式是使用 Quality Dashboard，但是全方位的 Quality Dashboard 都是每个项目根据自身情况自定义开发的，所以需要一定的定制化和开发成本，导致有些项目并不愿意投资这样的 Quality Dashboard，而用一些通用的局部质量 Dashboard，比如 SonarQube 等。虽然这些通用的解决方案只能度量和展示部分质量状态和质量风险，但是在没有办法提供全方位的定制化的 Quality Dashboard 情况下也是非常有用的。

2.1.6 是否需要了解其他团队的业务需求？如果需要，有哪些高效的方式来实现？

首先，这个问题的答案是需要了解，但是不需要精通。其目的是为了可以设计出更有效，更全面的测试用例。而最高效的方法是参加其他团队的 Story Elaboration 和 Showcase，在这样的会上面可以在最短的时间内了解其他团队开发的业务功能。

2.2 人员

所有的工作都是由人来完成的，所以人员是最为重要的一个关键点，所以基于人员的问题和痛点也不少。

2.2.1 如果有外包 QA 人员，如何管理外包 QA 人员？

由于大型项目一般都需要很多人，而公司储备的技术人员很大可能都不足，所以很多大型项目或多或少都会有一些外包人员，甚至有些大型项目整体全部外包给另外一个公司来开发。而对于团队中有外包 QA 人员的时候，最大的难题就是如何对齐其的能力，保证其工作有效性和工作产出。所以管理外包 QA 人员首先是通过面试和培训对其他们很团队内部 QA 的能力， 然后通过团队反馈，测试策略，测试流程，测试系统，流水线等流程和基础设施来规范工作内容，通过 Quality Dashboard 上的度量数据来工作产出和有效性。

2.2.2 分布式 QA 人员如何高效协作？

很多大型团队中的不同的团队很有可能分布在同一个国家中的不同的城市，甚至是不同的国家，不同的时区，从而导致协作比较困难。如果要做到高效协作，最主要是需要统一协调，主动同步，知识共享和及时响应等。统一协调是指在整个项目级别需要一个 Program QA Lead 来统一协调 QA 的工作，从而可以尽量避免由于信息不同步所带来的工作浪费，以及由于没有全局观所导致的错误决策。主动同步是指不同团队的 QA 需要主动将自己团队中的一些测试和质量相关的工作信息同步给其他团队，从而避免造成一些工作上的冲突或者浪费。知识共享是需要有一个统一的地方将不同团队以及通用的知识进行发布和共享，比如通过一个统一的 Google Doc 的文件夹或者一个统一的 Confluence 工作空间来共享 QA 所需要的知识及时响应就是每个团队的 QA 都需要对其他团队的需求以及遇到的问题及时响应，但是肯定不是每一个问题都需要及时响应，应该有一个统一的优先级标准，对于紧急并且重要的要第一时间响应，而重要并不紧急的可以稍缓响应，但是需要给出一个大概的响应时间。以上是最主要的四点实践，除此之外还有一些需要根据不同团队的真实情况而定制一些的实践。只有高效的实施这些协作的实践，分布式团队中的 QA 才能高效协作。

2.2.3 如何构建高效的 QA 人员能力建设机制，加速人员成长速度？

能力建设往往都一个非常困难的问题，因为它涉及到主观意愿的问题，而不是只靠制度就可以完美解决的。往往过于严苛的培养制度，会直接让被培养者放弃，所以好的培养制度一定是双向满意，并且张弛有度的。首先，高效的能力建设制度的第一步，一定是如何选择愿意建设自己能力的人员，而不是拒绝的人，特别是内心不愿意在测试与质量领域提升能力的人员。其次，需要有针对项目的所需技能的培训课程，让 QA 能快速掌握项目所需的基本技能。最后，每个团队的 QA Lead 和 PM 需要针对每个 QA 制定各自的成长计划和工作目标，并且需要细化到可以落地操作的程度，比如学习哪个工具，掌握到什么程度，学习什么方法，在项目中需要落地实施等等。并且建立团队反馈机制，让团队中的每个人快速的对需要能力建设的人进行及时反馈其问题，从而帮助其快速成长。所有高效的能力建设制度首先是正确的选择愿意提升能力的人员，然后通过体系化的项目培训以及团队定制化培养和反馈机制，最终加速人员的成长速度。

2.3 技术

技术是相对单一并且固定的，并且变动也不会很大，所以基于它的问题相对较少。

2.3.1 如何统一选择测试技术栈？

这里说到的技术主要是指自动化测试技术，针对它的选择是一个非常敏感的话题，因为它不仅涉及实施成本，学习成本等问题，更重要的还涉及到资源复用的问题。对于一个小项目，资源复用也许没有那么重要，但是对于一个大型的项目，特别是人员多的项目，资源复用就特别重要，因为节约的不少成本。这里所谓的资源复用主要是指自动化测试代码和产品代码之间的资源复用，以及 QA 人员和 Dev 人员之间的复用。

所以选择测试技术栈的时候，为了实现这两者的复用，一般尽可能选择和产品开发一样的技术栈，比如一个后台基于 Java 开发的微服务系统，前端是一个 React 的 Web 系统，则自动化测试可以选用基于 Java 的 REST Assured 来做 Web API 自动化测试，基于 Java 的 Gatling 来做性能测试，基于 JavaScript 的 PlayWright 来做前端 Web 功能测试。从而统一了开发和测试的技术栈，并且在测试人员不足，可以复用 Dev 人员来写自动测试，这个是我经常使用的方法。

但是对于一些无法复用 Dev 人员的团队中，可以退而求其次，尽可能的统一所有不同类型的自动化测试技术栈，从而降低学习成本，比如选用基于 JavaScript 的 Cypress 来做前端 Web 功能测试和后端 Web API 的自动化测试，选用基于 JavaScript 的 K6 来做性能测试，从而统一开发技术栈。但是相对于降低学习成本所带来的收益，我认为复用所带来的收益更大，所以在能复用开发的情况下，尽量选择和产品开发一样的技术栈。

2.3.2 跨团队的技术栈，是否有必要完全统一？在什么情况下可以统一，什么情况下不建议统一？

在大型项目中，最理想的情况是统一所有团队的测试技术栈，从而可以节约大量成本。但是在现实情况中，不少团队基于各自的原因，没有或者不能统一他们的技术栈。首先，如果不同团队开发的是同一个系统的不同组件，或者是同一个系统的不同业务功能。在这种情况下，一般都建议统一技术栈。但是如果不同的团队开发的是不同的子系统，而且不同的子系统之间都是通过消息队列（MQ），远程过程调用（RPC）等这种协议进行通信，并且不同子系统之间还是使用了不同的开发技术栈，这种情况下就不建议统一。

3 总结

以上这些痛点在小型的敏捷团队中或许不是很大的问题，或者说比较容易解决。但是一旦团队大了，项目复杂度很高的情况下，它们就会成为非常突出的问题，并且解决起来的困难度也急剧增加，并且有些问题有可能无法解决，只能通过增加成本来减弱其对于团队的影响，比如实施契约测试和第三方服务的 Schema 测试等。如果你有机会参与一个大型软件，并且还有机会实施敏捷开发和敏捷测试，希望本文的总结能帮助你提前认识到这些问题，并且当遇到的时候能尽快解决和改善，甚至能提前实施一些实践，阻止这些问题的发生，从而做到事半功倍。

原文：大规模团队中的敏捷测试实践 - 软件测试与质量沉思