大规模敏捷测试怎么做（基础篇）
本文由赵泽鑫，张海云，冯曌合作出品
大多数的敏捷团队是由10位以内不同角色的人员组建。其中包括但不仅限于BA、QA、UX、PM、DEV等关键角色。我们通过成熟的方法论以及每日站立会议（Stand-up Meeting）、迭代计划会议（Iteration Plan Meeting）、迭代启动会议（Iteration Kickoff Meeting，IKM）、开卡（Kickoff）、结卡（Desk Check，DC）和回顾会议（Retrospective）等各种逐渐“标准化”的敏捷活动，能够顺利地运行一个小规模的项目。
然而，当项目规模逐渐增大、项目成员人数逐渐增加时，为了有效协作，我们需要将整个大规模团队拆分为多个小规模的敏捷小组。但组与组之间的业务交互频繁，组内以及组间的各种沟通交流，会让原本快捷有效的敏捷活动变得繁琐。
尤其对于测试来说，小规模的项目中一般配有一到两名QA，负责所有功能模块的测试工作。但大规模的项目中，QA不仅要关注本组内的功能，同时还要考虑组与组间存在关联功能的测试。那么如何在高节奏的迭代中，进行大规模敏捷测试呢？
在大规模敏捷测试中，每个小组都需要贯彻执行良好的敏捷实践，以保障每个模块的高质量交付，从而获得最终的高质量产品。在这些基础敏捷实践中，QA一直扮演着质量推动者的角色，不断补充团队的质量视角，保障每个小环节的交付质量，形成层层质量防护网。
在大规模项目中，为了保证执行效率和质量标准的一致性，我们需要统一实施原则和节奏，定义主要的活动和规范。该项目采用的是两周一个迭代的方式，主要的活动包括：迭代开始会议（Iteration Kickoff Meeting，IKM）、站会（Stand-up Meeting）、开卡（Kickoff）、结卡（Desk Check）、阶段性成果展示（Showcase）和回顾会议（Rstrospective）等。在每个活动中，QA可以通过以下方式补充质量视角：
在每个迭代开始之前，团队会进行IKM阶段。在这个阶段，BA会澄清需求，以确保团队成员对目标有清晰的理解。同时，团队成员也会从各自的视角提出问题，以对齐理解并确保团队的一致性。此外，BA还将对本迭代目标进行澄清，以确保整个团队都知道要实现什么目标，并为此共同努力。
在IKM阶段中，QA的参与非常重要。如果QA的精力允许，最好能够在IKM之前就预先熟悉需求，检查验收标准，并从全局质量的视角提出问题。常见的问题包括是否考虑到边缘情况、异常场景和其他模块的一致性，性能、安全和第三方接口的确认等。如果QA经验充足，对系统的设计有全面了解的情况下，甚至可以对解决方案、架构等都提出质量相关质疑，以确保团队在设计和实现过程中更加注重质量。
在开卡阶段，由开卡的Dev来主导，BA和QA参与。Dev会说明自己对AC（Acceptance Criteria，验收标准）的理解并提出问题，以澄清一些细节和边界，确保团队对需求的理解一致。除了可以与团队一起完善和澄清AC外，QA还可以根据DC场景给出输入，列出比较重要的场景和检查点，以便Dev在完成开发后更充分的自测，也能够在结卡前提前准备好测试场景和数据。Dev在开发的过程中，会根据要实现的功能列出任务清单，这样可以梳理开发思路的同时也能让其他角色更了解故事卡的实现细节。
站会是敏捷实践中的典型活动，每天固定时间15分钟，大家进行一个站会沟通。但是在实施中，不同的团队有不同的更新方式。一些团队采用以人为视角的方式，每个人依次更新自己昨天完成的工作、今天要完成的工作以及遇到的问题和困难。这种方式比较适合多人协作完成一个大的任务，但对于多个任务卡片，每个卡片有不同的负责人的情况，比较难追踪每个任务的进展和问题。
为了加强卡片进展的追踪，我们团队采用了以看板内容为中心，对不同状态的卡片进行更新。之后再更新看板以外的事情，以及一些需要全体注意的问题。这种方式可以让大家更清晰地了解每张卡的进度和问题，从而了解迭代的整体进度。例如，在迭代即将结束前几天如果仍然有很多卡片在开发中，大家就可以迅速达成共识，加快结卡速度，为测试留出充足的时间。
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很容易获得全局观，把控质量全景。然而，当产品规模和团队规模大到一定程度，即使没有那么复杂的架构，仅仅是团队之间的协作也会面临诸多挑战。大规模敏捷最大的问题就是不同团队之间的协作。疫情的影响以及成本的压力导致团队成员分布在多地，远程合作成为常态。如何避免远程合作带来的不便，同时仍然进行充分、高效的沟通呢？
固定时间进行开卡、结卡，对应的角色BA、QA会预留开结卡时间，避免时间冲突约不到人导致的团队空转情况。
由于远程工作的原因，我们经常无法进行面对面或电话实时沟通，而即时信息工具又会导致信息刷屏，各种信息交织。那么如何才能及时地传递与某个方面相关的信息和意见呢？我们可以巧妙地利用工具。每次沟通的结果只要涉及其他成员或角色，就应在对应的故事卡中进行记录。
QA应该进行分诊，确保信息充分，避免多次沟通。对于QA来说，远程工作带来的沟通成本要求他们对发现的问题做出更明确的分诊。在描述缺陷时，应该包括场景、操作、现象、接口是否返回正确或错误的值，并在有日志时提供截图。然后将问题分派给相应故事卡的前端或后端。
多个QA协作，共用服务部署可能造成环境不稳定，这时就需要实时的信息沟通。项目采用微服务架构，不同的组负责维护不同的服务。当改动涉及公共服务的时候，会有比较大范围的影响。所以不能各自为营，需要各个组的QA进行透明的信息管理，当部署公共服务的时候需要提前在信息群中进行通知。对公共服务提供的接口要有清晰的了解，这样在测试过程能够快速定位问题，同时也能及时通过CI的状态排除一些由于环境问题引起的缺陷。
在大型项目中，不同的业务和模块之间存在交集和相互依赖，由于不同小组的开发进度和优先级不同，但是小组之间又会经常存在功能或数据层面的相互依赖，从而阻塞开发和测试活动，需要BA/PM/TL与相关团队协调进度或者考虑使用mock的方式跳过，并建立联调卡以显示依赖，并与各个模块对齐优先级。当对应的模块准备就绪后，进行联调之前需要尽量列举联调测试需要的场景。联调之前需要尽量列举联调测试需要的场景，等双方都开发完成后，及时进行系统内部的联调，测试通过后，后续如果有调整并且会影响到其他模块，则需要及时同步，以保证业务流的连贯性。
QA驱动质量维度的团队协作
QA还可以通过QA驱动的方式来增强团队的协作和质量意识。QA成员从需求评审开始就参与到项目中来，通过提前策划测试方案、制定测试计划、提供测试服务和评估测试结果等方式，来推动整个团队的质量意识和测试水平。
QA需要及时把控迭代进度，以免测试时间被挤压。而当测试完成度存在风险的时候，QA要及时跟团队寻求帮助，协调资源。QA将质量理念通过问题的形式不断地传递给团队其他成员，提高团队的质量意识。当团队中其他小伙伴有带宽支持测试的时候，QA可以将测试用例作为输入，测试点作为参考给到团队成员。同时根据不同人对不同业务的理解合理地安排工作，最大化地利用资源完成测试。
在大规模项目中实践敏捷测试，团队内部以及团队间的协作是非常有挑战的，既要有统一的目标，规范，原则，又要满足不同团队的不同情况，风格和文化。在实践中，我们可以根据不同团队的风格进行调整，以适应不同的情况。然而，最关键的是要先统一目标，再遵循规范，最后才是个性化的实践。
如果目标不能统一，规范不能遵循，即使小团队效率很高，也会为后期的集成埋下隐患。因此，在大规模项目中，我们需要加强团队之间的沟通与交流，建立起良好的合作关系，确保每个团队都能明确项目目标，并遵循相同的规范和原则。只有团队内部有良好的敏捷实践，同时加强团队间沟通交流，大家都有统一明确的目标，才能取得项目的成功。
- 相关阅读 -