大规模敏捷测试怎么做？-- 基础篇

写在前面该项目是某企业 CRMERP 系统 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站会开卡DCShowcase回顾会等。每个活动中 QA 究竟如何补充质量视角呢利用 IKM 进行需求澄清保障质量需求被识别每个迭代刚刚开始的时候会进行 IKMIKM 阶段 BA 澄清需求团队成员对齐理解各自根据自己的视角提问BA 会对本迭代目标进行的澄清。这里 QA 一定要参与到 IKM 中来如果精力足够最好是能够在 IKM 之前就预先熟悉需求检查验收标准并从全局质量的视角提出问题。常见的问题包括是否考虑到 Edge case异常场景和其他模块的一致性性能安全第三方接口确认等。如果 QA 准备充足甚至可以对解决方案架构等都提出质量相关质疑。利用开卡进行验证点澄清保障对质量需求与开发理解一致开卡阶段由开卡的 dev 来 driveBA、QA 参与。Dev 说明自己对 AC 的理解和提问澄清一些细节以及边界。保证大家理解的一致性。QA 除了可以一起完善、澄清 AC 外也可以根据 DC 场景给出输入列一下比较重要的场景和 check point这样开发可以在做完卡自测的更加充分也可以 DC 前提前准备好测试场景和数据。Dev 在做卡的时候会根据要实现的功能列 tasking这样梳理清晰开发思路的同时也能让其他角色更了解故事卡的实现细节。利用站会对齐关键质量信息站会是敏捷实践中的典型活动每天固定时间 15 分钟大家进行一个站会沟通。但是在实施中不同的团队却有不同的方式。有的团队是以人为视角每个人去更新自己昨天做了什么今天要做什么有什么困难和阻碍。可是这样的方式聚焦在个人身上无法形成全景图。更新完之后大家对于整体的进度和问题对全局的影响并没有一个清晰的认识。后来团队尝试了以板子内容为中心对不同状态的卡片从右往左更新。之后再更新板子之外的事情以及一些共性需要全体注意的问题。这种方式不仅效率提高大家对于整个迭代都有了全局视角如果在第二周有很多将要积压的 ready for QA 的卡片大家会迅速达成共识帮助尽快完成。QA 要利用站会的机会引导大家的质量意识比如一些普遍的质量问题一些严重的质量问题以及质量风险都可以通过站会传递这些关键信息强化团队的质量意识。推动开发质量内建质量内建是我司的特色也是质量保障的重要手段。在巨大的客户进度压力下我们开发小伙伴还是保持了单元测试 甚至一部分接口测试的实践覆盖率达到 60%-80%为代码的质量增加了一层结实的防护网。同时每天固定时间的 Code Review 也是非常好的一个实践不仅可以对代码进行一个团队评审同时也是一个培训新人不断强化代码规范的环节。QA 如果有时间有精力参与代码评审是个很好理解和学习代码的机会这将有助于 QA 更精准地评估质量风险。但是大多时候 QA 角色任务繁重很难有带宽参与到这个活动中。利用 Desk CheckDC进行需求实现澄清识别风险点Desk Check 也是开发发起BA 和 QA 参与。DC 的时候会重新过 AC如果有额外场景需要演示也可以直接进行演示。这个过程中 QA 会对实现方案以及风险点有一个更深入的了解。在 DC 时QA 也要引导性的问一些问题挖掘实现方案和代码变动对其他功能的影响、一些交叉功能点的风险情况、以及对其他模块和产品的依赖和影响从而为后续测试找寻到合适的方向。故事卡测试DC 结束后QA 会进行故事卡的测试故事卡测试一般采用根据 AC 验证加探索性测试的形式。QA 需要在开卡结束到 DC 的过程中根据故事卡的 AC、边缘场景以及自己对业务上下文的理解进行用例的编写。DC 结束后 QA 要根据优先级以及业务的关联性对故事卡进行功能测试此外还需进行必要的探索性测试若在测试过程中发现存在不能进行测试的集成测试场景要记录下来在后续集成测试阶段完成相关场景的测试。利用 Showcase 与产品和业务进行澄清并进行初步集成检验质量内建成果在大规模的项目中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 驱动质量维度的团队协作作为团队中的质量守护者QA 需要及时把控迭代进度以免测试时间被挤压。而当测试完成度存在风险的时候要及时跟团队寻求帮助协调资源。平时在各个环境中 IKM开卡结卡Showcase 时将质量理念通过问题的形式不断地给团队小伙伴宣讲提高团队的质量意识。当团队中其他小伙伴有带宽支持测试的时候可以更容易地上手。QA 可以将测试用例作为输入测试点作为参考给到团队成员。同时根据不同人对不同业务的理解合理的安排工作最大化的利用资源完成测试。一点感悟在大规模项目中团队内部以及团队间的协作是非常有挑战的既要有统一的目标规范原则又要满足不同团队的不同情况风格和文化。以上只是我在执行过程中的一些小的实践可以针对不同的团队风格进行不同的调整。最关键的是团队协作一定要先统一目标再符合规范最后才是个性化的实践。目标如果不能统一规范不能符合即使小团队效率很高也会为后期的集成埋下隐患。由于篇幅较长这次分享的是基础篇后续我们将陆续推出 SIT 集成篇UAT 验收篇等敬请期待。写在后面写在后面这么大规模 0-1 数字化转型也不太常见参与其中有欢乐也有汗水借此分享给大家希望你能读到一些不一样的感悟。这个项目还处在比较原始的阶段即使有很多很好的很优秀的实践但是不见得就适合这个阶段的旅程所以如果你读到了比较基础且常见的部分也希望能够理解在当下所采用的策略。当然一定有很多很多可以改进和提高的地方如果大家有兴趣也希望来一起讨论优化。比如自动化比如测试策略比如... 欢迎大家加入。最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。