在如今的大环境下你是否选择测试岗？—

在如今的大环境下你是否选择测试岗？——打造敏捷测试团队

news2024/12/27 12:25:16

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

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

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

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

从测试角度理解敏捷理念

首先，我们用极简的语言提出一个灵魂拷问，并尝试从测试的角度给出见解。
什么是敏捷？测试人员应该怎样理解敏捷理念？

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

请添加图片描述

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

敏捷宣言

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

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

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

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

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

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

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

敏捷原则12条

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

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

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

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

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

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

敏捷实践框架

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

为什么要做敏捷

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

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

+ 请添加图片描述

小结

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

请添加图片描述