作者：赵泽鑫，张海云，冯曌 ｜ QE-LAB
写在前面：该项目是某企业 CRM+ERP 系统 0 - 1 的数字化转型中最重要的一个产品之一，需要拉通上下游 30+ 系统，有上百名的同事与我们共同在一线战斗。我们将项目上的实践，遇到的问题，以及我们的辛酸苦辣落笔为大家眼前这些朴实的文字，希望能够给大家带来在大规模项目中做敏捷测试的不一样体验，感受大规模 0 到 1 数字化转型中的 QA 的机遇与挑战。
由于篇幅很长，将分成几个部分陆续介绍给大家。这一篇先介绍项目中敏捷测试的基础实践。
敏捷方法已经在我司实践落地多年，大多数的敏捷团队是由 10 位以内不同角色的人员组建。其中包括但不仅限于 BA、QA、UX、PM、DEV 等关键角色。我们通过成熟的方法论以及 stand up meeting、ipm、 ikm、kick off、desk check、retro 等各种逐渐 “标准化 “的敏捷活动，能够顺利地运行一个小规模的项目，但是当项目规模逐渐增大，项目成员人数逐渐增加，将整个大规模的团队拆分为多个小规模的敏捷小组后，由于组与组之间的业务交互频繁，组内以及组间的各种沟通交流就会让原本快捷有效的敏捷活动变得臃肿。尤其对于测试来说，小规模的项目中一般配有一到两名 QA，负责所有功能模块的测试工作。但大规模的项目中，QA 不仅要关注本组内的功能，同时要考虑组与组间的存在关联功能的测试。那么如何在高节奏的迭代中，进行大规模敏捷测试呢？那就通过在某手机大厂的数字化转型产品的测试经历来和大家一起分享一下我的看法和感悟吧。
大规模敏捷测试的基础是每个小组能够贯彻执行良好的敏捷实践，保障每个模块的高质量交付，才能获得最终的高质量产品。而在这基础敏捷实践中，QA 始终扮演着质量推动者的角色，在每个环节中不断补充团队的质量视角，保障每个小环节的交付质量，形成层层质量防护网。
大规模项目中，需要统一实施原则和节奏，定义主要的活动和规范。该项目采用的两周一个迭代的方式，主要的活动包括：IKM，站会，开卡，DC，Showcase，回顾会等。每个活动中 QA 究竟如何补充质量视角呢？
每个迭代刚刚开始的时候会进行 IKM，IKM 阶段 BA 澄清需求，团队成员对齐理解，各自根据自己的视角提问，BA 会对本迭代目标进行的澄清。
这里 QA 一定要参与到 IKM 中来，如果精力足够最好是能够在 IKM 之前就预先熟悉需求，检查验收标准，并从全局质量的视角提出问题。常见的问题包括是否考虑到 Edge case，异常场景，和其他模块的一致性，性能，安全，第三方接口确认等。如果 QA 准备充足，甚至可以对解决方案，架构等都提出质量相关质疑。
开卡阶段由开卡的 dev 来 drive，BA、QA 参与。Dev 说明自己对 AC 的理解和提问，澄清一些细节以及边界。保证大家理解的一致性。QA 除了可以一起完善、澄清 AC 外，也可以根据 DC 场景给出输入，列一下比较重要的场景和 check point，这样开发可以在做完卡自测的更加充分，也可以 DC 前提前准备好测试场景和数据。Dev 在做卡的时候，会根据要实现的功能列 tasking，这样梳理清晰开发思路的同时也能让其他角色更了解故事卡的实现细节。
站会是敏捷实践中的典型活动，每天固定时间 15 分钟，大家进行一个站会沟通。但是在实施中，不同的团队却有不同的方式。有的团队是以人为视角，每个人去更新自己昨天做了什么，今天要做什么，有什么困难和阻碍。可是这样的方式聚焦在个人身上，无法形成全景图。更新完之后大家对于整体的进度和问题对全局的影响并没有一个清晰的认识。后来团队尝试了以板子内容为中心，对不同状态的卡片从右往左更新。之后再更新板子之外的事情，以及一些共性需要全体注意的问题。这种方式不仅效率提高，大家对于整个迭代都有了全局视角，如果在第二周有很多将要积压的 ready for QA 的卡片，大家会迅速达成共识，帮助尽快完成。
QA 要利用站会的机会引导大家的质量意识，比如一些普遍的质量问题，一些严重的质量问题以及质量风险都可以通过站会传递这些关键信息，强化团队的质量意识。
质量内建是我司的特色，也是质量保障的重要手段。在巨大的客户进度压力下，我们开发小伙伴还是保持了单元测试甚至一部分接口测试的实践，覆盖率达到 60%-80%，为代码的质量增加了一层结实的防护网。同时每天固定时间的 Code Review 也是非常好的一个实践，不仅可以对代码进行一个团队评审，同时也是一个培训新人，不断强化代码规范的环节。
QA 如果有时间有精力参与代码评审，是个很好理解和学习代码的机会，这将有助于 QA 更精准地评估质量风险。但是大多时候 QA 角色任务繁重，很难有带宽参与到这个活动中。
Desk Check 也是开发发起，BA 和 QA 参与。DC 的时候会重新过 AC，如果有额外场景需要演示也可以直接进行演示。这个过程中 QA 会对实现方案以及风险点有一个更深入的了解。在 DC 时，QA 也要引导性的问一些问题，挖掘实现方案和代码变动对其他功能的影响、一些交叉功能点的风险情况、以及对其他模块和产品的依赖和影响，从而为后续测试找寻到合适的方向。
DC 结束后，QA 会进行故事卡的测试，故事卡测试一般采用根据 AC 验证加探索性测试的形式。QA 需要在开卡结束到 DC 的过程中根据故事卡的 AC、边缘场景以及自己对业务上下文的理解进行用例的编写。DC 结束后 QA 要根据优先级以及业务的关联性对故事卡进行功能测试，此外，还需进行必要的探索性测试，若在测试过程中，发现存在不能进行测试的集成测试场景，要记录下来，在后续集成测试阶段完成相关场景的测试。
在大规模的项目中，Showcase 是个非常重要的环节。在关键结点上，对完成的关键功能进行 Showcase，一方面可以极大地增加客户的信心，他们可以真切地感受到阶段性的成果，同时还可以收集到一线业务用户的反馈，便于我们进行及时的调整。我们的 Showcase 会分为迭代内的 showcase 和 milestone 的 showcase 两种，迭代内的 showcase，更注重细节和业务逻辑，从用户侧获得反馈；Milestone 阶段的 showcase，主要是面向客户的领导层，更注重业务价值和系统逻辑和实际业务的贴合度。不管是哪种类型的 showcase，都要注意收集反馈，对有价值的修改和理解不一致的业务进行研究讨论，改进系统功能，让其能更贴合业务，产生更大的价值。
从质量的维度来说，Showcase 可以更早的进行和其他模块的初集成，即使是为了跑通一个最基础的场景，也需要经历打包，初始化环境，部署，配置，初始化数据等环节。当初为了第一个 showcase，部署 SIT 环境花了两周的时间，经历的各种问题还历历在目。但是它却为开发提供了宝贵的可视化反馈，让开发意识到配置管理（包括环境配置和参数配置）的重要性，接口设计的合理性等等，可以在后续开发中不断地改进，为后续的持续集成打下一个坚实的基础。
这里想提一下缺陷管理。缺陷管理针对测试过程中发现的问题，使用缺陷管理工具，进行统一规范管理。其实敏捷中，很多团队都放弃了缺陷的记录。因为团队小，直接给开发一说，就修复了，会觉得记录缺陷是个浪费。但是在大规模的敏捷测试中，我们还是建议团队对缺陷进行规范的管理，在后期集成测试时，牵扯到多个模块和产品，更需要通过对缺陷的洞察，不断地调整测试策略和方向。在缺陷报告中必填信息包括不仅限于：缺陷的严重程度，修复优先级，发现阶段，指派给相关开发，复现步骤，缺陷当前状态，缺陷类型以及发生的原因。同时这个项目中客户对于缺陷修复时长也做了一定的要求。比如阻塞缺陷要求当天修复，严重要求 24 小时修复等。但是也不太建议要求太死，毕竟这样的度量就是你要求什么就会得到什么。很多时候为了避免缺陷延期，就把严重的降级为普通的，反而使缺陷记录失真，无法为后续测试提高真实的数据参考。
规范化的缺陷管理，能促进团队各角色成员的参与和关注度，能有效地推进缺陷的修复，能明晰的反馈出各迭代缺陷的实时动态，能为后续缺陷分析和开发质量的提升提供佐证和指明方向。我们在后期集成阶段，每日站会上通过缺陷来进行集成中发现问题的各种信息交流，有效地促进了问题的解决。同时也通过对缺陷的分析加强了同类问题的预防。
回归会议是非常重要的一个环节，它不仅可以让大家对过去一个迭代进行回顾，及时调整策略，更重要的是它提供了一个机会或者说平台，让大家可以参与如何改进的意见，是赋予团队每个成员主人翁意识的绝佳时机，尤其对于平时话语权不多的 QA 同学，更是一个不可多得的窗口来引导大家的质量意识。可惜很多团队并没有抓住这样的一个机会。要么因为时间紧，任务重就跳过了这个环节，要么是走形式，并没有做到真正的思考。
即使是有回顾会议，测试人员如果没有做准备，将质量通过数据，事件等回归的方式慢慢渗透，也很难利用这个机会。
可惜的是这个项目中回顾会议并没有执行的很到位。
一点感悟：除了采用敏捷的团队，也有团队采用小瀑布方式在同步开发其他的模块。虽然也采用两周一个迭代的节奏，但是两周内还是迭代所有功能开发完成再交给测试去测。没有层层的需求澄清环节，比如开卡结卡这些不断对齐需求的过程。经常听到这些团队的 QA 抱怨开发根本没有理解需求就进行开发，导致很多返工。同时开发因为能力和带宽问题，不愿意做单元测试，没有质量内建意识，结果也是可想而知，他们开发的模块发现的问题高出 2-3 倍之多，更是经常改一个问题引入两个问题。虽然开发不断地加班，修 bug 速度惊人（曾经从中午到第二天早晨关掉 30 多个 bug），但却只能让系统越来越脆弱，甚至在后期集成中爆发更多的问题。
一个小的团队进行敏捷测试实践是比较可控的，QA 很容易获得全局观，把控质量全景。然而当产品规模和团队规模大到一定程度，即使没有那么复杂的架构，单是团队之间的协作都要面临诸多的挑战。大规模敏捷最大的问题就是不同团队之间的协作。疫情影响以及成本的压力，导致团队成员分布在多地，远程的合作变成常态。如何避免远程合作带来的不便，仍旧进行充分，高效地沟通呢？
固定时间进行开结卡，对应的角色 BA、QA 会预留开结卡时间，避免时间冲突约不到人导致的团队空转情况。
很多时候由于远程，我们很难面对面或者电话实时沟通，即时信息工具又会导致信息刷屏，各种信息交织。那怎么能及时地传递关于某一个方面的信息和意见呢？我们可以巧妙地利用工具。 每次沟通的结果只要影响到其他成员或者角色，都会在对应的故事卡上 comment 进行记录。QA 分诊，做到信息充分，避免多次沟通。对于 QA 来讲，远程带来的沟通成本要求对发现的问题做出更明确的分诊，描述缺陷的时候要带有场景，在什么前提下，进行什么操作，发生了什么现象，接口有没有对应的正确的或者错误的返回值，有日志的话给出日志截图，分派给对应故事卡的前端或后端。
多个 QA 协作，共用服务部署可能造成环境不稳定，这时就需要实时的信息沟通。 项目采用微服务架构，不同的组负责维护不同的服务。当改动涉及到公共服务的时候，会有比较大范围的影响。所以不能各自为营，需要各个组的 QA 进行透明的信息管理，当部署公共服务的时候需要提前在信息群中进行通知。对公共服务提供的接口要有清晰的了解，这样在测试过程能够快速定位问题，同时也能及时通过 CI 的状态排除一些由于环境问题引起的缺陷。
项目规模大，会有很多业务与其他模块的业务存在交集，功能存在交互。每个团队都有自己负责的模块，不同小组的开发进度和优先级不同，这会导致小组之间存在功能或数据层面的相互依赖，进而引发对开发、测试活动造成一定程度的 block，这时候要 BA/PM/TL 与相关团队协调进度或者考虑使用 mock 的方式跳过，并建立联调卡显示化依赖，并和各个模块对齐优先级，待对应的模块 ready 后进行联调。联调之前需要尽量列举联调测试需要的场景，等双方都开发完成后，及时进行系统内部的联调，测试通过后，后续再有调整且会影响到其他模块的要及时同步，保证业务流的连贯性
因为所在的项目是 0-1 的整体数字化转型，牵扯到多达十几个产品一起上线，和第三方系统联系极为紧密，很多集成的接口需要和其他系统的人对接，经过反复讨论才定义下来。这种情况下一定要将对齐的结果以文字或者邮件形式保留，即使是平台上有信息，也要额外备份，保证在后续有接口变动的时候有迹可循。否则在后续集成拉通过程中，接口的变化将带来巨大的成本和质量的风险。
作为团队中的质量守护者，QA 需要及时把控迭代进度，以免测试时间被挤压。而当测试完成度存在风险的时候要及时跟团队寻求帮助，协调资源。平时在各个环境中 IKM，开卡结卡，Showcase 时，将质量理念通过问题的形式不断地给团队小伙伴宣讲，提高团队的质量意识。当团队中其他小伙伴有带宽支持测试的时候，可以更容易地上手。QA 可以将测试用例作为输入，测试点作为参考给到团队成员。同时根据不同人对不同业务的理解合理的安排工作，最大化的利用资源完成测试。
一点感悟：在大规模项目中团队内部以及团队间的协作是非常有挑战的，既要有统一的目标，规范，原则，又要满足不同团队的不同情况，风格和文化。以上只是我在执行过程中的一些小的实践，可以针对不同的团队风格进行不同的调整。最关键的是团队协作一定要先统一目标，再符合规范，最后才是个性化的实践。目标如果不能统一，规范不能符合，即使小团队效率很高，也会为后期的集成埋下隐患。
由于篇幅较长，这次分享的是基础篇，后续我们将陆续推出 SIT 集成篇，UAT 验收篇等，敬请期待。
写在后面：这么大规模 0-1 数字化转型也不太常见，参与其中有欢乐也有汗水，借此分享给大家，希望你能读到一些不一样的感悟。这个项目还处在比较原始的阶段，即使有很多很好的很优秀的实践，但是不见得就适合这个阶段的旅程，所以如果你读到了比较基础且常见的部分，也希望能够理解在当下所采用的策略。当然，一定有很多很多可以改进和提高的地方，如果大家有兴趣也希望来一起讨论优化。比如自动化，比如测试策略，比如... 欢迎大家加入。
