下载掌阅APP，畅读海量书库
立即打开
敏捷转型大潮汹涌而来，各大技术公司均被卷入其中，在管理层的重视下，效能提升成为测试团队日常工作的口头禅。但是我们也看到，敏捷转型的效果参差不齐，真正深入理解敏捷要义的骨干员工数量很少，对敏捷概念的误解很多，转型打法上经常发生冲突，团队成员也频频感到受挫。
身处其中的测试团队往往陷入更加困惑的状态，一方面交付要快，另一方面质量兜底的挑战并未减少，这使得测试人员身心俱疲，甚至成为转型中的消极角色。为什么会身心俱疲，问题究竟出在哪里？
本章就从“什么是敏捷测试”以及“敏捷测试为什么会失败”开始剖析，并介绍对测试团队的敏捷现状做出自我诊断的过程。
首先，我们用极简的语言提出一个灵魂拷问，并尝试从测试的角度给出见解。
什么是敏捷？测试人员应该怎样理解敏捷理念？
敏捷知识体系本质上是一棵大树，从下到上，树根是敏捷宣言和价值观（ 道 ），树干是敏捷原则（ 法 ），树枝和树叶是各种层出不穷的实践方法框架（ 术 ），如图1-1所示。
敏捷宣言
对于敏捷宣言，大家应该耳熟能详了，它是敏捷实践先驱给出的共识：一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下的价值观。
图1-1 敏捷知识之树——道、法、术
❑个体与交互 胜过 过程与工具
❑可用的软件 胜过 详细的文档
❑客户协作 胜过 合同谈判
❑响应变化 胜过 遵循计划
尽管右侧有其价值，但我们更重视左侧的价值。
敏捷宣言对于测试活动的启发与思考总结如下 。
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等。
为什么要做敏捷
在日新月异的技术高速发展的背景下，软件架构和跨软件交互的复杂度被提升到前所未有的高度。大量的行业数据告诉我们，传统研发模式遇到巨大的挑战，三分之二的功能很少甚至从来没有被客户使用，后期需求变更持续不断，但质量修复成本不断攀升。
引入敏捷的本质，就是把传统项目管理铁三角——范围、时间和成本，进化为敏捷铁三角价值、质量和约束条件，如图1-2所示。在现有的 约束条件（可能是时间、成本或范围） 下，我们会以 高质量 优先完成 高价值 的事情。
图1-2 传统项目管理铁三角与敏捷铁三角
敏捷测试 究竟是什么意思？
从2011年在某大厂开设“敏捷测试”课程至今，我对敏捷测试的理解从懵懵懂懂开始历经了几轮重新解读，这里跟大家分享下。
从定义上可以用一句话概括， 敏捷测试就是遵循敏捷价值观和原则的所有测试活动 。
结合1.1节的敏捷理念，我对敏捷测试的具体解读包含如下几个方面：
❑强调从用户角度来测试系统，而不仅仅从产品设计逻辑角度，甚至在测试活动中加入足够的真实用户，快速搜集到意见。
❑强调尽早开始测试，频繁地验收测试，有节奏地测试，而不是像传统流程一样强调测试的准入门槛。
❑测试不局限在特定阶段。换句话说，测试活动贯穿整个软件生命周期，包括上线后的监控、分析和改进。改进不只是增加场景用例，更是精简用例。
❑测试不局限在某个岗位，所有角色都应该参与一定的测试活动，认同质量内建文化，把质量标准纳入需求估算，共同为质量事故负责。
❑质量方面的投入永远是有限的，商业项目不可能追求过于昂贵的质量改进行动。因此，只谈质量不谈付出的成本，就是无稽之谈。
❑敏捷测试策略兼具计划式测试和探索式测试的优点，不在前期过度设计，在执行中发挥人员的主观能动性。
❑敏捷测试要在各种测试活动中排除不相关的干扰，减少与业务不相关的繁文缛节。测试人员在特性交付团队内能自主工作并快速获得支持。
很多人把敏捷测试理解为自动化测试，或者持续交付中的持续测试，我认为这个理解是非常狭隘的。
自动化测试并不是帮助测试团队敏捷转型成功的银弹 ，因为：
❑如果测试分析和设计能力不足，用例质量不高，那么做再多的自动化测试也发现不了问题。自动化主要用来做已有功能的回归保障。
❑自动化测试收益不一定能满足组织预期，有时候是用来掩盖测试团队真正短板的遮羞布，看着运行数据挺漂亮，可能实际价值很低。
❑脚本数量越大，维护成本越高，不及时更新就越会有杀虫剂效应（就像庄稼长期用一种杀虫剂会致使害虫逐渐具有抗药性一样），导致有效缺陷率也会越来越低。
❑它解决不了测试团队的低效沟通问题。
❑它通常发现不了用户关心的体验问题。
❑自动化测试项目并不会让所有测试人员都受益，很多测试人员在自动化实践中获得的专业能力提升很有限。
在关于敏捷理论的大量经典著作中，自动化测试的工程保障内容只占比例非常小的一块。更多方向的价值有待测试团队去挖掘，这也是本书各章会展开探讨的。
首先，基于观察到的案例总结一下一个 公司的敏捷转型为什么会失败 。最常见的原因如下。
1） 高级管理层没有足够的决心，或者过于乐观/悲观。
转型本身会改变大家的工作流程和习惯，而敏捷又是跨多个不同岗位/部门的协作。我们把单一职能部门称为“竖井”，即只完成垂直一块的职责，如果没有高级管理者的大力支持，敏捷转型一定会在“竖井”之间的高墙阻碍下步履蹒跚。
有些高级管理者对敏捷转型有投资意愿，但是对其价值目标缺乏清楚的认识，虽然邀请了专家顾问主导，转型启动时声势浩大，投资不菲，但是过一段时间没有看到明显的成效，马上就偃旗息鼓了。
2） 部分管理者因为权力被触动，在敏捷转型中消极对待。
敏捷原则的落实，需要特性团队自主决策、信息透明、成员平等。原先的管理者需要放弃强力干预的风格，在考核上做出让权，而且不能利用信息不对等谋求个人的影响力。管理者不管是否在一线特性交付团队，都需要调整自己的心态和工作方式，即 从命令者/指导者变为服务者 。
无法转变心态的管理者，有可能对敏捷转型的新流程和效果持负面看法，也有可能强行“加戏”，在转型目标中加入不必要的内容以凸显自己的主导地位。
敏捷转型试点团队以外的管理者，有可能针对试点敏捷中的小失误，向高管抱怨，否定继续敏捷转型的必要性。
官本位的管理者，往往把管理下属的人数作为自己权力大小的体现。在原来职能部门的竖井管理模式中，员工创造的价值是不太透明的。而在敏捷特性团队的模式中，每一个全职人员交付了多少价值，相对是清晰透明的，这样很容易把原来职能团队的人力水分挤出去，导致管理规模缩小。这也是一小部分管理者对敏捷持警觉态度的原因。
3） 团队初期充满干劲，但并没有深入理解敏捷。
对于这种情况，随着时间的推移，通常团队会越来越疲乏，转型负责人身心俱疲，员工信心受挫。
团队可能缺乏一个精通敏捷的有影响力的教练，缺乏一个循序渐进的理解敏捷的过程。负责人可能非常热情，通过各种调研给出了改进现状的各种措施，研发平台也上线了大量提效功能，团队在初期像打了鸡血一样往前冲。但需要敏捷改进的地方实在太多了，在业务压力下，激情难以持续。利用工具平台提升效率的场景通常很零散，难以统一团队认识，如果大家内心连基础的敏捷原则都没有遵守，再强大的工具平台也无济于事。而且，被设计得越来越复杂的平台，会让员工更加有抵触情绪。
正确的做法应该是先全员学习敏捷课程，演练基本技巧，明确三驾马车（敏捷教练、产品负责人、技术负责人）的角色职责，从初期到中长期，循序渐进。工具平台仅作为配套支持，从简单功能到进化功能，逐步上线。
4） 组织架构缺乏激励。
在公司激励制度不足的情况下，有可能出现试点团队很成功，但是并没有得到任何收益，甚至团队被迫解散的情况；也有可能发生一旦支持变革的领导离职，敏捷转型就走向沉默的现象。
一个长期支持敏捷成果落地的组织架构非常重要，它的目标就是让敏捷先行者根据收益得到回报，激励其他团队转型，同时也给予足够的自治权。
所有特性团队的内部考核流程也很关键，这和单一职能部门的内部考核完全不同。敏捷团队考核强调的是集体成功导向，个人被团队认可，职能部门管理者（如果有的话）最多保留部分考核权力，让业务成功的特性团队整体上都得到更多的激励，其中受团队爱戴的核心角色应该得到更多的晋升机会。
当然，除了这4种主要的失败原因，还有很多其他原因，这里不一一展开。
让我们再从 测试人员的角度 来看转型失败还有哪些原因值得更进一步剖析。
1） 测试人员没有深入理解敏捷，并利用好它。
不少测试人员认为“敏捷”就是个虚架子，给我们徒增麻烦，让本就紧张的交付周期变得更加紧张，加班也会更加严重。
这些都是对敏捷的误解。测试人员没有认真理解敏捷的精髓，白白错过了 通过它保护自己劳动成果 的机会，也可能让自己总是被不懂敏捷的其他角色瞎指挥，最终得出“敏捷没啥用”的错误认知。这类错误认知还会让其他负面因素恶化，加速失控。
2） 老流程考核还在，新敏捷流程也要搞。
这是很常见的敏捷转型失败的原因。测试人员经常诉苦，原先制定的复杂流程和考核指标一个没少，新敏捷的各种纪律保障和指标又不断增加，感觉在同时打两份工，自然对敏捷行动产生抵触情绪。
敏捷变革应该从试点项目开始，重新塑造交互流程和交付标准，而不是背着历史包袱。尤其是要去除测试人员“质量兜底”的心理负担，树立起质量事故的全员担当文化，根据用户反馈数据来调整敏捷交付的质量标准。
敏捷需求和任务分工方面，让测试人员的精力得到可持续保障，把测试类任务充分纳入排期（结合需求的优先级），让测试人员得到自主开展工作的充分授权。
3） 缺乏技术提升机会，测试人员流失。
因为敏捷特性团队的目标是快速交付产品，而测试人员在其中可能感觉势单力薄，被辅导的机会很少，所以很多人在快节奏下逐步放弃了对测试技术的打磨，最终影响了自己的晋升，甚至被迫离开团队，去追求更磨练技术的岗位。人员流失则加重了自动化保障缺乏的困境，陷入恶性循环。
快速交付产品的基础保障就是测试技术的高效能，这需要跨特性团队的测试领域负责人（或专家）提供更多的横向拉通和技术辅导机会。所以，测试人员分配到各个特性团队做全职工作，并不意味着原先的测试主管或测试架构师就只能做甩手掌柜。同时，每个特性团队也要在迭代排期中预留测试技术债的偿还时间，并给予较高的优先级。
4） 测试变成打杂的。
与上一个原因类似，如果敏捷团队的主导者不重视专业测试的价值，不重视测试类工作，把项目当前低优先级的各类工作去填满测试人员的工作区，必将导致测试人员缺乏成就感。
这种情况也暴露了特性团队并非处于“平等、自治”和追求全栈能力的状态，违反了“共同为质量负责”的原则。对于可以跨角色完成的工作，可以遵循自愿分工、按估算分配的模式。如果现阶段不希望在专业测试任务上花费太多精力，建议不在团队里安排全职的测试工程师，指派组织内的其他测试工程师参与技术评审和验收阶段把关即可。
最后，我们对敏捷测试的认知做一下 纠偏 ：
❑所有敏捷理论中 保护开发活动效能的道理，也适用于测试活动 。
❑测试人员也会面临与开发人员一样的困扰：被频繁打扰、被浪费成果、被怀疑专业度、没有精力完成技术债。
❑测试活动的任务排期、估算、完成速率、优先级等，也是需要统一纳入敏捷规划中的。
因此，测试团队需要建立 信任、自主、透明、共建 的敏捷测试文化，真正融入整个敏捷转型组织之中。
理解了敏捷知识和失败原因，我们可以开始逐步诊断团队自身，共同研讨，一起制定未来的转型目标。
打造敏捷团队与打造成功的敏捷产品有一定的相似性，团队成员对未来愿景能否达成共识，对如何达到愿景的主要措施能否达成共识，至关重要，这是指导未来具体交付行为的指南针。
基于我的亲身实践，下面将从团队管理者或者教练的角度推荐一下自我诊断流程。
空降团队的管理者或者教练需要与有代表性的成员做单独交流，为后面最重要的脑暴会做准备。访谈对象还可以包括最密切的关键合作方。
单独访谈需要营造放松安全的氛围，主要关心受访者对下列五类问题的真实看法。
1） 外部干系人对我们测试角色的最大期望是什么？ 包括质量上的期望和效率上的期望，哪些专业工作做得不够到位，遗留的风险比较大。哪些工作最需要测试团队的支持（服务）。
2） 哪些知识和能力的缺乏，阻碍了我们提升效率和质量？ 包括业务知识、测试技术知识、培训资源、管理认知等，获取这些信息的渠道如果不通畅，原因是什么？
3） 哪些最常见的外部干扰严重阻碍了测试交付的效率？ 类似的问题是，测试人员被迫等待和加班的主要原因是什么，可否规避？
4） 测试交付的主要活动成果中，价值偏低的有哪些？ 这些低价值成果，如果不做会怎么样？测试人员对承担低价值工作的情绪如何？自动化测试的建设，产出价值符合预期吗？
5） 哪些当前的组织问题阻碍了测试的敏捷转型？ 包括激励因素、安全感、官僚习惯、部门墙、专家指导等。
组织诊断的负责人提前对搜集到的突出问题做归类和提炼，作为现场脑暴会的背景信息。对于意想不到的问题，要做更多的探寻。需要的话，可以结合突出问题相关的历史数据和典型报告进行分析判断。
准备一个能充分研讨的会议室，预留至少4h的会议时间，邀请团队核心骨干、角色代表和新人代表参与，请大家带着吐槽和期待前来。脑暴会要务虚，不要演变为具体问题的辩解和解决措施评审，也不要变成错误检讨会。
负责人按照一定的会议议程严格控场，但也要安排比较充分的吐槽和讨论时间，最终得出一系列团队诊断和共识成果。
下面是个人推荐的引导做法，可以根据脑暴会的时长对产出目标及数量进行裁剪，或者分两轮来研讨。
❑阻碍测试人员提高交付效率的典型事件有哪几种？评选出最严重的 TOP 5阻碍事件 。
❑为了实现业务人员和管理者的期待，测试团队面临的最典型风险有哪几个（种）？评选出 TOP 5风险。
❑针对测试团队的能力现状做 SWOT 分析（优势、劣势、外部机会、外部威胁），各选出TOP 1～3（不超过3个）。
❑基于以上讨论，畅想一下测试团队未来3～5年应该是什么样子。 用一句话描述团队发展的愿景 。大家投票确认共识成果，之后会把愿景写在公共区域。
❑团队向着正确的愿景方向前进，在敏捷转型实践中，应该遵守什么敏捷原则？从测试团队关心的角度进行投票，选出 TOP 5敏捷测试原则 。
❑综合以上分析，为了向愿景进发， 未来一年团队要完成的具体举措是什么？选出3～5个挑战举措 ，可以是降低TOP风险的，可以是提高测试效率的，也可以是提高专业品质的。
会议结束后，如果无异议，负责人可以用史诗故事的描述方式（类比产品需求概念中的大型完整需求，可以拆解为多个具体特性和故事场景）把TOP举措（也包括团队愿景描述）录入团队工作空间或WIKI里，让所有成员随时可以看到。将来可以进一步把这个史诗故事通过充分研讨拆解为子举措、个人目标、阶段性目标等，排期跟进完成。
为了方便读者理解诊断分析后的最终共识成果是什么样子，本节提供一个具体的示例作为参考，相信会对多数测试团队有所启发，但具体到每个团队，还需要根据自己的个性化痛点和诉求进行调整。
测试团队转型愿景示例
成为业界领先的高效能游戏测试团队。
说明 ：愿景立足于团队自身，是对团队未来3～5年的美好状态的憧憬。对愿景的描述不需要具体，业务大方向通常是长期稳定的，但业务具体规则和项目计划则每年都会变。从多年经验来看，敏捷、高效能、转型、业界领先、一流、品质、测试技术、用户体验、价值等关键词被愿景选中的概率比较高。
确定愿景的目的是从信念上把大家拧成一股绳，面向未来长期合作、共同奋斗。
敏捷测试原则示例
1）必须优先处理超过48h的测试环境阻塞事件，公布原因和处理措施。
2）在所有新增测试需求被接受前，必须给出需求方理由、针对的风险等级，以及测试成本。
3）应该将所有质量审批流程设计为并行，不能串行，非关键角色审批可以忽略。
4）对于所有紧急的加班测试及发布版本，需给出必须紧急发布的充分理由。
说明：敏捷原则就是一句话说清楚如何操作的共识，是跨不同场景都能适用的抽象指导。这是因为工作场景五花八门，洋洋洒洒写一堆细化规则反而无法传播主旨。既然是原则，一定是挑选最典型的痛点，通过严格执行来落实敏捷价值观。
补充：也可以挑选几个价值观的关键词，作为敏捷测试原则的进一步提炼，方便所有成员牢牢记忆，比如“show me the code”，流程去中介，拒绝浪费，少发报告，单测先行，劳逸结合，等等。
第2章还会提炼更多的敏捷测试知识点，读者可以将其作为自己团队敏捷测试原则的候选。
重大举措示例
示例一：重点参与三个试点项目的敏捷转型，测试交付效能提升指标达成情况，梳理出与敏捷测试相关的通用总结。
示例二：针对敏捷原则刷新现行的所有测试流程规范，通过评审在团队中宣导和常规执行。
说明：重大举措相当于团队要完成的年度史诗故事，制定后还需要多次讨论其实现方案、里程碑、考核指标、个人分工等。举措描述要符合SMART。相关的辅助工作，如调研和培训，可以纳入拆解出来的子举措中（相当于一个个特性需求的实现）。
可以通过 敏捷研发管理系统 去跟进落实所有相关的大小举措，这与普通产品需求研发的管理过程没有什么不同。
测试团队SWOT分析示例
优势：分层自动化测试平台比较完善，工程师普遍掌握了自动化测试技能。
劣势：线上低级漏测情况严重，经常被质疑用例设计能力不足，测试占用周期太长，没有时间提升自动化覆盖率。
外部机会：客服部和试用用户平台愿意配合测试部，完善漏测问题的快速分析和验证，参与灰度测试活动。
外部威胁：黑盒执行团队人力比同行庞大，效率较低，管理层考虑大幅收缩编制。
说明：SWOT分析是我们在明确愿景之前对自己的深刻剖析，分析的结果就是让高价值的长板更长，并集中力量补齐阻碍我们达成愿景的关键短板。
TOP风险示例（针对测试交付）
业务交付风险：智能语音产品没有明确的质量验收范围，可测试场景数量巨大，导致交付周期长，而且线上吐槽不断。
团队发展风险：自动化测试建设口碑平平，核心工程师兴致索然，离职风险加大。
说明：最典型和严重的风险，也是制定年度举措的重要输入，因为除了一定要建设的成果，也有一定要防范的危险，否则业绩目标就可能功亏一篑。而TOP风险可以从业务交付视角和团队内部健康发展视角来提炼，内外需兼顾。
我经常在敏捷转型的启动会议上把导致转型彻底失败的风险摊开，做个“事前追悼”的思维碰撞：请每个与会者都说一说， 如果我们按照商议的计划去执行，一年后测试团队敏捷转型仍然惨败，那最有可能的导火索是什么。
这个问题可以更直接地激发员工深入思考本质风险，找出值得纳入举措的遗漏点。以下是可能的导火索示例：
❑领导朝令夕改，放弃转型计划，不提供资源支持。
❑一线测试人员仍然独自背负着质量兜底的责任，拒绝拥抱敏捷，甚至大量离职。
❑测试人员的专业水平跟不上，无法支持整个特性团队的每日持续测试。漫长的测试周期和强硬的通过标准，间接影响业务发布节奏。
需要更多武器？
有了诊断结果和行动目标，如何为各位读者输送合适的强力“武器”，提升关键能力，帮助愿景的达成？
每个团队的专业度和境遇不同，对于敏捷测试的指导需求也不同。敏捷测试的工具箱非常丰富，在一段时期内并不需要同时展开实践，以避免负担过大。
本书后面将为读者提供不同细分领域的理论与实操方案，帮助测试团队走向更有生命力的敏捷组织形态。读者阅读后可结合自身需求采取行动。
本章从敏捷理念的知识开始介绍，阐述了敏捷宣言和原则对于测试活动的启发，引出敏捷测试的定义。针对为什么公司的敏捷转型会失败以及为什么敏捷测试会失败，本章也给出了观察到的主要现象和原因。接下来，引导测试团队对最突出的阻碍和风险进行自我诊断，通过集体脑暴对团队愿景、敏捷测试原则和关键举措达成共识，并持续付诸行动。