如何打造一支敏捷测试团队

文章目录

摘要
01 从测试角度理解敏捷理念
- 什么是敏捷？测试人员应该怎样理解敏捷理念？
- 敏捷宣言
- 对于测试活动的启发与思考总结如下。
- 敏捷原则12条
- 敏捷实践框架
- 为什么要做敏捷
02 什么是敏捷测试
03 敏捷测试为什么会失败
04 诊断脑暴会的成果示例
- 敏捷测试原则示例
- 重大举措示例
- 测试团队SWOT分析示例
- TOP风险示例（针对测试交付）
05 小结
推荐理由
赠书活动

摘要

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

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

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

更多详细内容请参考《无测试组织：测试团队的敏捷转型》一书。
在这里插入图片描述

01 从测试角度理解敏捷理念

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

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

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

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

敏捷宣言

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

个体与交互胜过过程与工具
可用的软件胜过详细的文档
客户协作胜过合同谈判
响应变化胜过遵循计划

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

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

测试活动不能忽视人和人的交流，我们不能指望所有测试依赖的信息都列在需求和设计文档里，这在研发过程中是不现实的。测试管理者是否创建了各种激励手段，推动测试人员加大交流的有效性，而不是“逼迫”产品和开发人员升级更完善的文档？
从软件的使用中获得测试知识，而不是依赖死板的文档提供测试知识。如何尽早地使用软件，并尽可能多的获得测试需要的启发？
合同中约定的质量标准就是一成不变的铁律吗？为了让客户更及时地刷新质量交付要求，能否邀请他尽早参与测试活动，并从客户这里获得有益的测试信息？
被测需求的变更率越低越好吗？并非如此，优秀产品一定是快速响应需求的。测试团队不应该期待用户需求尽可能保持不变，而是应该建立能根据变更需求及时调整策略和用例的机制。

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

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

敏捷原则12条

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

通过尽早和持续地交付有价值的软件来满足客户。
欣然面对需求变化。
不断交付可用的软件，周期越短越好。
在项目过程中，业务人员和开发人员必须在一起工作。
激发个体的斗志。给他们所需要的环境和支持，并相信他们能够完成任务。
不论团队内外，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持长期稳定的开发步伐。
对技术的精益求精和对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队定期地反省如何提高成效，并相应地调整团队的行为。

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

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

由交付软件的周期越短越好推导出测试活动独占的时间越短越好，这应该是核心的度量指标。
我们的测试人员是否和开发、产品、业务人员坐在一起，紧密工作？如果并非如此，管理者如何减少异地工作的负面效应。
测试人员为了达成交付目标，是否获得了敏捷团队以及测试主管的支持，是否获得了足够的信任？
测试工作投入时间是否稳定，加班情况严重吗？可持续的测试工作，首先是避免长期的加班和没有规律的工作量安排。从敏捷观点来看，长期的加班模式不但不会提高迭代速率，反而会降低速率，有规律的作息是高效工作的基础保障。
是否有合理的人力持续投入测试技术的打磨优化上？
日常的测试工作中哪些是没有必要，可以被精简的？
测试策略和方案实施，多大程度上能由敏捷团队内部人员完全掌控，而不依赖外部专业人士协助？
定期的团队反省改进措施中，是否经常有测试改进的内容？改进效果如何？

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

敏捷实践框架

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

为什么要做敏捷

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

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

传统项目管理铁三角与敏捷铁三角

02 什么是敏捷测试

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

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

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

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

强调从用户角度来测试系统，而不仅仅从产品设计逻辑角度。甚至测试活动能够卷入足够的真实用户，快速搜集到意见。
强调尽早开始测试，频繁地验收测试，有节奏地测试，而不是像传统流程一样强调测试的准入门槛。
测试不局限在特定阶段。换句话说，测试活动贯穿整个软件生命周期，包括上线后的监控、分析和改进。改进不只是增加场景用例，更是精简用例。
测试不局限在某个岗位，所有角色都应该参与一定的测试活动，认同质量内建文化，把质量标准纳入需求估算，共同为质量事故负责。
质量方面的投入永远是有限的，商业项目不可能追求过于昂贵的质量改进行动。因此，只谈质量不谈付出的成本，就是耍流氓。
敏捷测试策略兼具计划测试和探索测试的优点，不在前期过度设计，在执行中发挥人员的主观能动性。
敏捷测试要在各种测试活动中排除不相关的干扰，减少与业务不相关的繁文缛节。测试人员在特性交付团队内能自主工作并快速获得支持。

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

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

如果测试分析和设计能力不足，用例质量不高，那么做再多的自动化测试也发现不了问题。自动化主要用来做已有功能的回归保障。
自动化测试收益不一定满足组织预期，有些时候是用来掩盖测试团队真正短板的遮羞布，看着运行数据挺漂亮，可能实际价值很低。
脚本数量越大，维护成本越高，不及时更新就会有杀虫剂效应（就像庄稼长期播撒一种杀虫剂会致使害虫逐渐具有抗药性），导致有效缺陷率也会越来越低。
它解决不了测试团队的低效沟通问题。
它通常发现不了用户关心的体验问题。
自动化测试项目并不会让所有测试人员都受益，很多测试成员在自动化实践中获得的专业提升幅度很有限。

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

03 敏捷测试为什么会失败

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

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

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

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

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

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

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

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

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

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

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

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

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

组织架构缺乏激励。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4）测试变成打杂的。

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

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

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

所有敏捷理论中保护开发活动效能的道理，也适用于测试活动。
测试人员也会面临和开发人员一样的困扰：被频繁打扰、被浪费成果、被怀疑专业度、没有精力完成技术债。
测试活动的任务排期、估算、完成速率、优先级等，也是需要统一纳入敏捷规划中的。

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

04 诊断脑暴会的成果示例

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

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

敏捷测试原则示例

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

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

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

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

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

重大举措示例

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

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

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

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

测试团队SWOT分析示例

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

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

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

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

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

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

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

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

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

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

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

领导朝令夕改，放弃转型计划，不提供资源支持。
一线测试人员仍然独自背负着质量兜底的责任，拒绝拥抱敏捷，甚至大量离职。
测试人员的专业水平跟不上，无法支持整个特性团队的每日持续测试。漫长的测试周期和强硬的通过标准，间接影响业务发布节奏的达成。

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

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

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

05 小结

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