这是鼎叔的第五十八篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。
开始写本公众号的第五个主题专辑- 测试团队如何开始敏捷转型。
第一篇介绍敏捷的定义和核心知识，以及什么是敏捷测试。
背景
敏捷转型大潮汹涌而来，各大技术公司均被卷入其中，在管理层的重视下，效能提升成为测试团队日常工作的口头禅。但是我们也看到，敏捷转型的效果参差不齐，真正深入理解敏捷要义的骨干员工数量很少，对敏捷概念的误解随处可见，转型打法上经常发生冲突，团队成员也频频感到受挫。
身处其中的测试团队往往陷入更加困惑的状态，一方面交付要快，另一方面质量兜底的挑战并未减少，使得测试人员身心俱疲，甚至成为转型中的消极角色。事实上，鼎叔认为，在转型成功的敏捷研发团队之中，测试人员应该会得到足够多的收益，在工作时应该会更加愉悦舒心。为什么会身心俱疲，问题究竟出在哪里？
那我们先从敏捷理念开始聊起，并从测试角色的角度理解它。
什么是敏捷
首先，我们用极简的语言提出一个灵魂拷问，并尝试从测试的角度给出见解。
什么是敏捷？测试人员应该怎样理解敏捷理念？
敏捷知识体系本质上是一棵大树。从下到上，树根是敏捷宣言和价值观（道）；树干是敏捷原则（法）；树枝和树叶是各种层出不穷的实践方法框架（术）。
敏捷宣言
对于敏捷宣言，大家对此应该耳熟能详了，它是敏捷实践先驱们推出的共识：我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下的价值观。
个体与交互 胜过 过程与工具
可用的软件 胜过 详细的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
尽管右侧有其价值，但我们更重视左侧的价值。
对于测试活动的启发与思考总结如下：
1) 测试活动不能忽视人和人的交流，我们不能指望所有测试依赖的信息都列在需求和设计文档里，这在研发过程中是不现实的。测试管理者是否创建了各种激励手段，推动测试人员加大交流的有效性，而不是 “逼迫” 产品和开发人员升级更完善的文档？
2) 从软件的使用中获得测试知识，而不是依赖死板的文档提供测试知识。如何尽早地使用软件，并尽可能多的获得测试需要的启发？
3) 合同中约定的质量标准就是一成不变的铁律吗？为了让客户更及时地刷新质量交付要求，能否邀请他尽早参与测试活动，并从客户这里获得有益的测试信息？
4) 被测需求的变更率越低越好吗？并非如此，优秀产品一定是快速响应需求的。测试团队不应该期待用户需求尽可能保持不变，而是应该建立能根据变更需求及时调整策略和用例的机制。
注意，不要走向另一个极端！ 过程、工具、文档、合同和计划，对于研发团队和测试活动依然很重要，如果完全去掉它们，会带来什么后果呢？大概率是欲速而不达，甚至欲哭无泪。一旦重要成员变动，项目时间拉长，很多工作可能要从头再来。
我们的目标就是通过实践，在这些产物的投入度和使用价值上取得平衡。
敏捷原则十二条
敏捷原则 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, 等等。
为什么要做敏捷
在日新月异的技术高速发展的背景下，软件架构和跨软件交互的复杂度被提升到前所未有的高度。大量的行业数据告诉我们，传统研发模式遇到巨大的挑战，三分之二的功能很少甚至从来没有被客户使用，后期需求变更持续不断，但质量修复成本却不断攀升。
引入敏捷的本质，就是把传统项目管理铁三角——范围、时间和成本，进化为敏捷铁三角——价值、质量和约束条件。在现有的约束条件（可能是时间、成本或范围）下，我们会以高质量优先完成高价值的事情。
什么是敏捷测试
敏捷测试究竟是什么意思？
自从多年前在某大厂开设 “敏捷测试” 课程至今，鼎叔对敏捷测试的理解从懵懵懂懂开始历经了几轮的重新解读，这里跟大家分享下。
从定义上可以用一句话概括，敏捷测试就是遵循敏捷价值观和原则的所有测试活动。
结合上文的敏捷理念启发，我对敏捷测试的具体解读包含如下几个方面：
强调从用户角度来测试系统，而不仅仅从产品设计逻辑角度。甚至测试活动能够卷入足够的真实用户，快速搜集到意见。
强调尽早开始测试，频繁地验收测试，有节奏地测试，而不是像传统流程一样强调测试的准入门槛。
测试不局限在特定阶段。换句话说，测试活动贯穿整个软件生命周期，包括上线后的监控、分析和改进。改进不只是增加场景用例，更是精简用例。
测试不局限在某个岗位，所有角色都应该参与一定的测试活动，认同质量内建文化，把质量标准纳入需求估算，共同为质量事故负责。
质量方面的投入永远是有限的，商业项目不可能追求过于昂贵的质量改进行动。因此，只谈质量不谈付出的成本，就是耍流氓。
敏捷测试策略兼具计划测试和探索测试的优点，不在前期过度设计，在执行中发挥人员的主观能动性。
敏捷测试要在各种测试活动中排除不相关的干扰，减少与业务不相关的繁文缛节。测试人员在特性交付团队内能自主工作并快速获得支持。
注意：很多人把敏捷测试理解为自动化测试，我认为这个理解是非常狭隘的。下一篇会详细阐述原因。
