✅作者简介：大家好，我是Leo，热爱Java后端开发者，一个想要与大家共同进步的男人😉😉
🍎个人主页：Leo的博客
💞当前专栏： 赠书活动专栏
✨特色专栏： MySQL学习
🥭本文内容： Leo赠书活动-05期 【打造敏捷测试团队】文末送书5本
🖥️个人小站 ：个人博客，欢迎大家访问
📚个人知识库： 知识库，欢迎大家访问

1.前言

**摘要：**敏捷转型大潮汹涌而来，各大技术公司均被卷入其中，在管理层的重视下，效能提升成为测试团队日常工作的口头禅。但是我们也看到，敏捷转型的效果参差不齐，真正深入理解敏捷要义的骨干员工数量很少，对敏捷概念的误解随处可见，转型打法上经常发生冲突，团队成员也频频感到受挫。

身处其中的测试团队往往陷入更加困惑的状态，一方面交付要快，另一方面质量兜底的挑战并未减少，使得测试人员身心俱疲，甚至成为转型中的消极角色。事实上，我认为在转型成功的敏捷研发团队之中，测试人员应该会得到足够多的收益，在工作时应该会更加愉悦舒心。为什么会身心俱疲，问题究竟出在哪里？

本文从“什么是敏捷测试”以及“敏捷为什么会失败”开始剖析，并分享对测试团队的敏捷现状做出自我诊断的过程。

更多详细内容请参考**《无测试组织：测试团队的敏捷转型》**一书。

2.从测试角度理解敏捷理念

首先，我们用极简的语言提出一个灵魂拷问，并尝试从测试的角度给出见解。

什么是敏捷？测试人员应该怎样理解敏捷理念？

敏捷知识体系本质上是一棵大树。从下到上，树根是敏捷宣言和价值观（道）；树干是敏捷原则（法）；树枝和树叶是各种层出不穷的实践方法框架（术）。如图所示。

敏捷知识之树——道、法、术

敏捷宣言

对于敏捷宣言，大家对此应该耳熟能详了，它是敏捷实践先驱们推出的共识：我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下的价值观。

l个体与交互 胜过 过程与工具

l可用的软件 胜过 详细的文档

l客户协作 胜过 合同谈判

l响应变化 胜过 遵循计划

尽管右侧有其价值，但我们更重视左侧的价值。

对于测试活动的启发与思考总结如下。

1)测试活动不能忽视人和人的交流，我们不能指望所有测试依赖的信息都列在需求和设计文档里，这在研发过程中是不现实的。测试管理者是否创建了各种激励手段，推动测试人员加大交流的有效性，而不是“逼迫”产品和开发人员升级更完善的文档？

**2)**从软件的使用中获得测试知识，而不是依赖死板的文档提供测试知识。如何尽早地使用软件，并尽可能多的获得测试需要的启发？

3)合同中约定的质量标准就是一成不变的铁律吗？为了让客户更及时地刷新质量交付要求，能否邀请他尽早参与测试活动，并从客户这里获得有益的测试信息？

4)被测需求的变更率越低越好吗？并非如此，优秀产品一定是快速响应需求的。测试团队不应该期待用户需求尽可能保持不变，而是应该建立能根据****变更需求及时调整策略和用例的机制。

注意，不要走向另一个极端 过程、工具、文档、合同和计划，对于研发团队和测试活动依然很重要，如果完全去掉它们，会带来什么后果呢？大概率是欲速而不达，甚至欲哭无泪。一旦重要成员变动，项目时间拉长，很多工作可能要从头再来。

我们的目标就是通过实践，在这些产物的投入度和使用价值上取得平衡。

敏捷原则12条

敏捷原则12条的具体内容如下。

1)通过尽早和持续地交付有价值的软件来满足客户。

2)欣然面对需求变化。

3)不断交付可用的软件，周期越短越好。

4)在项目过程中，业务人员和开发人员必须在一起工作。

5)激发个体的斗志。给他们所需要的环境和支持，并相信他们能够完成任务。

6)不论团队内外，最有效的沟通方法是面对面的交谈。

7)可用的软件是衡量进度的主要指标。

8)敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持长期稳定的开发步伐。

9)对技术的精益求精和对设计的不断完善将提升敏捷性。

10)要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11)最佳的架构、需求和设计出自于自组织的团队。

12)团队定期地反省如何提高成效，并相应地调整团队的行为。

这些敏捷原则是基于敏捷宣言进一步展开。

对于测试活动的启发与思考****总结如下。

1)由交付软件的周期越短越好推导出测试活动独占的时间越短越好，这应该是核心的度量指标。

2)我们的测试人员是否和开发、产品、业务人员坐在一起，紧密工作？如果并非如此，管理者如何减少异地工作的负面效应。

3)测试人员为了达成交付目标，是否获得了敏捷团队以及测试主管的支持，是否获得了足够的信任？

4)测试工作投入时间是否稳定，加班情况严重吗？可持续的测试工作，首先是避免长期的加班和没有规律的工作量安排。从敏捷观点来看，长期的加班模式不但不会提高迭代速率，反而会降低速率，有规律的作息是高效工作的基础保障。

5)是否有合理的人力持续投入测试技术的打磨优化上？

6)日常的测试工作中哪些是没有必要，可以被精简的？

7)测试策略和方案实施，多大程度上能由敏捷团队内部人员完全掌控，而不依赖外部专业人士协助？

8)定期的团队反省改进措施中，是否经常有测试改进的内容？改进效果如何？

把上述原则投射到测试活动管理中，并一一做好了，测试敏捷实践的成效就不会差。可惜，能有意识地遵守大部分敏捷原则的团队少之又少。

敏捷实践框架

即使有了敏捷宣言和原则，二者还是无法在研发过程中具体指引团队完成敏捷转型。通过多年的研究和探索，各类敏捷实践框架应运而生，各具优势，能满足通用或特定团队情况。著名的敏捷实践框架有Scrum、看板、TDD/ATDD、DDD、BDD、CI/CD、PAIR、SAFe, 等等。

为什么要做敏捷

在日新月异的技术高速发展的背景下，软件架构和跨软件交互的复杂度被提升到前所未有的高度。大量的行业数据告诉我们，传统研发模式遇到巨大的挑战，三分之二的功能很少甚至从来没有被客户使用，后期需求变更持续不断，但质量修复成本却不断攀升。

引入敏捷的本质，就是把传统项目管理铁三角——范围、时间和成本**，进化为敏捷铁三角——价值、质量和约束条件。在现有的约束条件可能是时间、成本或范围）下，我们会以高质量优先完成高价值的事情。

3.什么是敏捷测试

敏捷测试究竟是什么意思？

从2011年在某大厂开设“敏捷测试”课程至今，我对敏捷测试的理解从懵懵懂懂开始历经了几轮的重新解读，这里跟大家分享下。

从定义上可以用一句话概括，敏捷测试就是遵循敏捷价值观和原则的所有测试活动。

结合前文的敏捷理念启发，我对敏捷测试的具体解读包含如下几个方面：

l强调从用户角度来测试系统，而不仅仅从产品设计逻辑角度。甚至测试活动能够卷入足够的真实用户，快速搜集到意见。

l强调尽早开始测试，频繁地验收测试，有节奏地测试，而不是像传统流程一样强调测试的准入门槛。

l测试不局限在特定阶段。换句话说，测试活动贯穿整个软件生命周期，包括上线后的监控、分析和改进。改进不只是增加场景用例，更是精简用例。

l测试不局限在某个岗位，所有角色都应该参与一定的测试活动，认同质量内建文化，把质量标准纳入需求估算，共同为质量事故负责。

l质量方面的投入永远是有限的，商业项目不可能追求过于昂贵的质量改进行动。因此，只谈质量不谈付出的成本，就是耍流氓。

l敏捷测试策略兼具计划测试和探索测试的优点，不在前期过度设计，在执行中发挥人员的主观能动性。

l敏捷测试要在各种测试活动中排除不相关的干扰，减少与业务不相关的繁文缛节。测试人员在特性交付团队内能自主工作并快速获得支持。

很多人把敏捷测试理解为自动化测试，或者持续交付中的持续测试，我认为这个理解是非常狭隘的。

自动化测试并不是帮助测试团队敏捷转型成功的银弹，因为：

l如果测试分析和设计能力不足，用例质量不高，那么做再多的自动化测试也发现不了问题。自动化主要用来做已有功能的回归保障。

l自动化测试收益不一定满足组织预期，有些时候是用来掩盖测试团队真正短板的遮羞布，看着运行数据挺漂亮，可能实际价值很低。

l脚本数量越大，维护成本越高，不及时更新就会有杀虫剂效应（就像庄稼长期播撒一种杀虫剂会致使害虫逐渐具有抗药性），导致有效缺陷率也会越来越低。

l它解决不了测试团队的低效沟通问题。

l它通常发现不了用户关心的体验问题。

l自动化测试项目并不会让所有测试人员都受益，很多测试成员在自动化实践中获得的专业提升幅度很有限。

在敏捷理论的大量经典著作中，自动化测试的工程保障内容只占比例非常小的一块。更多方向的价值有待测试团队去挖掘，更多详细内容请参考**《无****测试组织：测试团队的敏捷转型》**一书。

4.敏捷测试为什么会失败

首先，基于观察到的案例总结一下，一个公司的敏捷转型为什么会失败？

**1）**高级管理层并没有足够的决心，或者过于乐观/悲观。

转型本身会改变大家的工作流程和习惯，而敏捷又是跨多个不同岗位部门的协作。我们把单一职能部门被称为“竖井”，即只完成垂直一块的职责，如果没有高级管理者的大力支持，敏捷转型一定会在“竖井”之间的高墙阻碍下步履蹒跚。

有些高级管理者对敏捷转型有投资意愿，但是对其价值目标缺乏清楚的认识，虽然邀请了专家顾问主导，转型启动时声势浩大，投资不菲，但是过一段时期没有看到明显的成效，马上就偃旗息鼓了。

**2）****部分管理者因为权力被触动，在敏捷转型中消极对待。

敏捷原则的落实，需要特性团队自主决策，信息透明，成员平等。原先的管理者需要放弃强力干预的风格，在考核上也做出让权，而且不能利用信息不对等谋求个人的影响力。管理者不管是否在一线特性交付团队，都需要调整自己的心态和工作方式，即从命令者指导者变为服务者。

无法转变心态的管理者，有可能对敏捷转型的新流程和效果持负面看法。也有可能强行“加戏”，在转型目标中加入不必要的内容以凸显自己的主导地位。

置身事外的管理者，也有可能针对试点敏捷中的小失误，向高管提出抱怨，否定继续敏捷转型的必要性。

官本位的管理者，往往把管理下属的人数作为自己权力大小的体现。在原来职能部门的竖井管理模式中，员工创造的价值是不太透明的。而在敏捷特性团队的模式中，每一个全职人员交付了多少价值，相对是清晰透明的，这样很容易把原来职能团队的人力水分挤出去，导致管理规模缩小。这也是一小部分管理者对敏捷持警觉态度的原因。

**3）**团队初期充满干劲，但并没有深入理解敏捷。

对于这种情况，通常随着时间的推移，团队会越来越疲乏，转型负责人身心俱疲，员工信心受挫。

团队缺乏一个精通敏捷的有影响力的教练，缺乏一个循序渐进的理解敏捷的过程。负责人可能非常热情，通过各种调研给出了改进现状的各种措施，研发平台也上线了大量提效功能，团队在初期像打了鸡血往前冲。但需要敏捷改进的地方实在太多了，在业务压力下，激情难以持续。利用工具平台提升效率的场景通常很零散，难以统一团队共识，如果大家内心连基础的敏捷原则都没有遵守，再强大的工具平台也无济于事。而且，被设计得越来越复杂的平台，会让员工更加有抵触情绪。

正确的姿势应该是先全员学习敏捷课程，演练基本技巧，明确三驾马车（Scrum Master，产品负责人，技术负责人）的角色职责，从初期到中长期，循序渐进，工具平台仅作为配套支持，从简单功能到进化功能，逐步上线。

4）组织架构缺乏激励。

在公司激励制度不足的情况下，有可能出现试点团队很成功，但是并没有得到任何收益，甚至团队被迫解散的情况。也经常发生一旦支持变革的领导离职，敏捷转型就走向沉默的现象。

一个长期支持敏捷成果落地的组织架构非常重要，它的目标就是让敏捷先行者根据收益得到回报，激励其他团队转型，同时也给予足够的自治权。

所有特性团队的内部考核流程也很关键，这和单一职能部门的内部考核完全不同。敏捷团队考核强调的是集体成功导向，个人被团队认可，职能部门管理者（如果有的话）最多保留部分考核权力，让业务成功的特性团队整体上都得到更多的激励，其中受团队爱戴的核心角色应该得到更多的专业晋升机会。

当然，除了这四种主要的失败原因，还有很多其他原因，这里暂且不一一展开。

让我们再从测试人员的角度来看转型失败，又有哪些原因值得更进一步剖析？

**1）**测试人员没有深入理解敏捷，并利用好它。

不少测试人员认为“敏捷”就是个虚架子，给我们徒增麻烦，让本就紧张的交付周期变得更加紧张，加班也会更加严重。

这些都是对敏捷的误解。测试人员没有认真理解敏捷精髓，白白错过了通过它保护自己劳动成果的机会，也可能让自己总是被不懂敏捷的其他角色瞎指挥，最终得出“敏捷没啥用”的错误认知。这类错误认知还会让其他负面因素恶化，加速失控。

**2）**老流程考核还在，新敏捷流程也要搞

这是很常见的敏捷转型失败原因。测试人员经常诉苦道，原先制定的复杂流程和指标考核一个没少，新敏捷的各种纪律保障和指标又不断增加，感觉在同时打两份工，自然对敏捷行动产生抵触情绪。

敏捷变革应该从试点项目开始，重新塑造交互流程和交付标准，而不是背着历史包袱。尤其是要去除测试人员的“质量兜底”心理负担，树立起质量事故的全员担当文化，根据用户反馈数据来调整敏捷交付的质量标准。

敏捷需求和任务分工中，让测试人员的精力得到可持续保障，把测试类任务充分纳入排期（结合需求的优先级），让测试人员得到自主开展工作的充分授权。

**3）**缺乏技术提升机会，测试人员流失。

因为敏捷特性团队的目标是快速交付产品，而测试人员在其中可能感觉势单力薄，被辅导的机会很少，所以很多人在快节奏下逐步放弃了对测试技术的打磨，最终影响自己的专业晋升，甚至被迫离开团队，去追求更磨练技术的岗位。人员流失又加重了自动化保障缺乏的困境，陷入恶性循环。

快速交付产品的基础保障就是测试技术的高效能，这需要跨特性团队的测试领域负责人（或专家），提供更多的横向拉通和技术辅导机会。所以，测试人员分配到各个特性团队做全职工作，并不意味着原先的测试主管或测试架构师就只能做甩手掌柜。同时，每个特性团队也要在迭代排期中预留测试技术债的偿还时间，并给予较高的优先级。

**4）**测试变成打杂的。

和上一个原因类似，如果敏捷团队的主导者不重视专业测试的价值，不重视测试类工作，把项目当前低优先级的各类工作去填满测试人员的工作区，必将导致测试人员缺乏成就感。

这种情况也暴露了特性团队并非处于“平等、自治”和追求全栈能力的状态，违反“共同为质量负责”的原则。对于可以跨角色完成的工作，可以遵循自愿分工，按估算分配的模式。如果现阶段不希望在专业测试任务上花费太多精力，建议不在团队里安排全职的测试工程师，指派组织内的其他测试工程师参与技术评审和验收阶段把关即可。

最后，我们对敏捷测试的认知做一下纠偏：

l所有敏捷理论中保护开发活动效能的道理*，也适用于测试活动。

l测试人员也会面临和开发人员一样的困扰：被频繁打扰、被浪费成果、被怀疑专业度、没有精力完成技术债。

l测试活动的任务排期、估算、完成速率、优先级等，也是需要统一纳入敏捷规划中的。

因此，测试团队需要建立信任****、自主、透明、共建的敏捷测试文化，真正融入到整个敏捷转型组织之中。如想了解更多详细内容请参考**《无测试组织：测试团队的敏捷转型》一书。

5.诊断脑暴会的成果示例

测试团队转型愿景示例

成为业界领先的高效能游戏测试团队。

说明：愿景立足于团队自身，是对团队未来3-5年的美好状态的憧憬。对愿景的描述不需要具体，业务大方向通常是长期稳定的，但业务具体规则和项目计划则每年都会变。从多年经验来看，敏捷、高效能、转型、业界领先、一流、品质、测试技术、用户体验、价值等关键词被愿景选中的概率比较高。

确定愿景的目的是从信念上把大家拉成一股绳，面向未来长期合作、共同奋斗。

敏捷测试原则示例

1） 必须优先处理超过48小时的测试环境阻塞事件，公布原因和处理措施。

2） 在所有新增测试需求被接受前，必须给出需求方理由、针对的风险等级，以及测试成本。
3） 应该将所有质量审批流程设计为并行，不能串行，非关键角色审批可以忽略。

4） 对于所有紧急的加班测试及发布版本，需给出必须紧急发布的充分理由。

说明：敏捷原则就是一句话说清楚如何操作的共识，需要是跨不同场景都能适用的抽象指导。因为工作场景五花八门，洋洋洒洒写一堆细化规则反而无法传播主旨。既然是原则，一定是挑选最典型的痛点，通过严格执行来落实敏捷价值观。

补充：我们也可以挑选几个价值观的关键词，作为敏捷测试原则的进一步提炼，方便所有成员牢牢记忆，比如：“show me the code”，流程去中介，拒绝浪费，少发报告，单测先行，劳逸结合，等等。

重大举措示例

示例一：重点参与三个试点项目敏捷转型，测试交付效能提升指标达成，梳理出敏捷测试相关的通用总结。

示例二：针对敏捷原则刷新现行的所有测试流程规范，通过评审并在团队中宣导和常规执行。

说明：重大举措相当于团队要完成的年度史诗故事，制定后还需要多次讨论其实现方案，里程碑，考核指标，拆解到个人的分工，等等。举措描述也要符合SMART。相关的辅助工作如调研和培训，可以纳入拆解出来的子举措中（相当于一个个特性需求的实现）。

可以通过敏捷研发管理系统去跟进落实所有相关的大小举措，这和普通产品需求研发的管理过程没有什么不同。

测试团队SWOT分析示例

优势：分层自动化测试平台比较完善，工程师普遍掌握自动化测试技能。

劣势：线上低级漏测情况严重，经常被质疑用例设计能力不足，测试占用周期太长，没有时间提升自动化覆盖率。

外部机会：客服部和试用用户平台愿意配合测试部，完善漏测问题的快速分析和验证，参与灰度测试活动。

外部威胁：黑盒执行团队人力比同行庞大，效率较低，管理层考虑大幅收缩编制。

说明：SWOT分析是我们在明确愿景之前对自己的深刻剖析，分析的结果就是让高价值的长板更长，并集中力量补齐阻碍我们达成愿景的关键短板。

TOP风险示例（针对测试交付）

业务交付风险：智能语音产品没有明确的质量验收范围，可测试场景数量巨大，导致交付周期长，而且线上吐槽不断。

团队发展风险：自动化测试建设口碑平平，核心工程师兴致索然，离职风险加大。

说明：最典型和严重的风险，也是制定年度举措的重要输入，因为除了一定要建设的成果，也有一定要防范的危险，否则业绩目标就可能功亏一篑。而TOP风险可以从业务交付视角和团队内部健康发展视角来提炼，内外需兼顾。

我经常在敏捷转型的启动会议上，把导致转型彻底失败的风险摊开，做个“事前追悼”的思维碰撞：请每个与会者都说一说，如果我们按照商议的计划去执行，一年后测试团队敏捷转型仍然惨败，那最有可能的导火索是什么？

这个问题可以更直接的激发员工深入思考本质风险，找出值得纳入举措的遗漏点。以下是可能的导火索示例：

l领导朝令夕改，放弃转型计划，不提供资源支持。

l一线测试人员仍然独自背负着质量兜底的责任，拒绝拥抱敏捷，甚至大量离职。

l测试人员的专业水平跟不上，无法支持整个特性团队的每日持续测试。漫长的测试周期和强硬的通过标准，间接影响业务发布节奏的达成。

需要更多武器？

有了诊断结果和行动目标，如何为各位读者输送合适的强力“武器”，提升关键能力，帮助愿景的达成？

每个团队的专业度和境遇不同，对于敏捷测试的指导需求也不同。敏捷测试的工具箱非常丰富，在一段时期内并不需要同时展开实践，避免负担过大。

**《无测试组织：测试团队的敏捷转型》**一书将为读者提供不同细分领域的理论与实操方案，帮助测试团队走向更有生命力的敏捷组织形态。欢迎读者阅读后结合自身需求采取行动。

6.小结

本文从敏捷理念的知识开始介绍，阐述了敏捷宣言和原则对于测试活动的启发，引出敏捷测试的定义。为什么敏捷转型会失败，为什么敏捷测试会失败？本章也给出了观察到的主要现象和原因。接下来，引导测试团队对最突出的阻碍和风险进行自我诊断，通过集体脑暴对团队愿景、敏捷测试原则和关键举措达成共识，并持续付诸行动。更多内容请参考**《无测试组织：测试团队的敏捷转型》**。

正版购书链接https://item.jd.com/14105386.html

这是一本从敏捷测试团队打造、敏捷测试技术修炼两个维度指导一线的测试团队和质量团队全面实现敏捷转型的著作。从一线测试团队和质量团队的视角出发，以解决测试工作中的实际困难为宗旨，以“敏捷效果”为挑选观点和素材的准绳，内容既不会随着技术的发展而过时，又能引发各类角色广泛深入地思考。

推荐理由：

（1）作者背景资深：阿里巴巴海外电商公司Lazada（东南亚旗舰电商平台）的执行副总裁，曾在阿里、腾讯、OPPO、小赢科技等多家知名科技公司从事测试技术和管理工作。

（2）作者经验丰富：在软件质量和测试领域深耕20余年，曾负责手机QQ、手机QQ浏览器、腾讯手机管家、应用宝等多个知名产品的测试项目和团队管理。

（3）顶流专家推荐：阿里P10高级总监、腾讯质量通道会长、微信测试总监等多位资深专家联袂推荐。

7.🥇赠书活动规则

🌟关注我的博客：关注我的博客，所有新鲜的博客文章和活动信息都不会错过。
📲添加博主wx：添加Leocisyam,如果添加不了,请私信博主。
💬参与方式：关注公众号程序员Leo或者文末扫码关注，回复抽奖，即可参与抽奖。
🎁公布结果：2023年11月9日晚，我会亲自抽取5️⃣名幸运读者，并在微信私信通知，请大家注意查收哈。