【每日一学 20260805】敏捷之道——敏捷项目下的传统测试转型之旅

2026-08-05 15:16:00
蓉蓉
原创
9


一、敏捷测试文化转变

敏捷文化是敏捷测试转型的基础，只有具备敏捷文化的氛围，对于组织架构、流程和相关测试实践的调整才有意义。在之前的敏捷测试定义中，我们知道敏捷测试是遵从敏捷软件开发原则的一种测试实践，因此敏捷的价值观、敏捷宣言和敏捷十二原则等同样在敏捷测试中适用。除此之外，从传统测试到敏捷测试的文化转变还包括了组织文化转变与管理文化转变等。

1.组织文化转变

（1）小心变成质量警察

在敏捷测试中，测试人员不再被赋予决定是否可以上线的权利。项目的上线不再是依赖某个人或者某个组，而是整个敏捷团队的决策。因此测试人员必须转变思想，不要有“测试人员是项目上线的判官”心理，从实际出发，根据敏捷测试的要求来指导测试。

（2）可持续的速度而不是在项目尾段快速激烈的测试
在敏捷测试中是不认可加班文化的。判断团队能否加班的一条原则就是团队能否保持可持续的速度。如果只是偶尔加班处理紧急的事情，不影响整体的交付速度，那无伤大雅；而如果是长期的加班使得测试人员处于一种疲劳、沮丧、情绪低落的状态，那就说明开发过程不可持续，需要做出改变。
（3）合作伙伴式的客户关系
在敏捷测试中，客户与测试人员不再是甲乙方关系，而是合作伙伴的关系，大家有同一个目标，那就是使项目成功。所，以客户会更频繁地参与到项目的各个方面，而测试人员也需要更主动地与客户进行沟通，了解客户需要什么、关注什么、担心什么，从而能更好地帮助测试工作。

2.管理文化转变

（1）每个团队都有能力做出决定
每个团队都有能力做出决定，能力有两层含义：一是外部相关，是指组织或者公司需要赋权给团队，让团队有权利自己去决定相关的决策；二是内部相关，是指团队内部必须有能力去判断和做出正确的决策。
（2）提倡免责文化
无论在敏捷还是DevOps领域都是提倡免责文化，即不把犯错误跟绩效考核挂钩。原因在于敏捷是基于经验性的，所以在敏捷的环境中，需要有不断创新、不断尝试的勇气。而创新尝试是有很高的失败风险。在这种情况下如果还是把失败与绩效挂钩，则会打击尝试者的积极性，久而久之大家宁愿墨守成规也不愿意尝试创新，最终整个组织或者项目将会失去不断自我改进的活力。
（3）管理层需要具备敏捷知识
有些管理层领导觉得敏捷是下面的人应该去学习的，因为他们是具体干活的，而管理层则没必要学习敏捷知识。这其实是一个错误的想法。在理查德·克纳斯特（Richard Knaster）和迪恩·莱芬韦尔（Dean Leffingwell）的著作《SAFe4.0精粹》一书中说到：企业的领导者必须拥抱精益-敏捷思维。如果领导者只是通过语言而不是他们自身的行动来支持敏捷，人们很快就会认识到他不是全心全意在推动变革。他们必须知晓方法，强调终身学习，需要用新的行为践行这些价值观、原则和实践。

二、敏捷测试组织转变

传统的项目组织是基于职能型组织架构，团队成员来自不同的职能部门，比如需求部门、开发部门、测试部门等。这种组织架构带来的问题之一就是沟通模式成为“N”型模式，效率非常低。

而在敏捷环境中，组织架构需要转变成为跨职能团队，即在团队里面会有不同技能的人员，可能包括业务分析、开发、测试，架构师，甚至是DBA等角色。在这种模式下，团队的沟通会变得更加直接和有效，成员之间无需经过间接的第三方进行沟通传达，而是经常可以直接面对面进行沟通，从而大大提高了沟通的效率。
组织架构调整后可能会出现测试人员的归属感问题。因为原来的测试部门没有了，测试人员担心他们的个人职业发展和技能培养由谁来关心。我们可以考虑成立测试实践社区（Testing Communities of Practice，TCoP）。在SAFe中是如此定义实践社区CoP的：实践社区是一个由团队成员和其他专家组成的非正式团体，他们在一个项目群或企业环境中活动，并且拥有在一个或多个相关领域分享实践知识的使命。由定义可知，虽然CoP不是一个正式的团体组织，无法承担测试人员管理的职责，但是至少可以让测试人员有一个精神乐园作为寄托，可以在里面学习与分享，减少测试人员的迷茫感。

三、敏捷测试流程转变

敏捷测试的流程根据敏捷测试类型也分为两类：一类是Sprint内敏捷测试流程；一类是跨Sprint敏捷测试流程。Sprint内测试流程主要是针对每个用户故事进行的验证测试；跨Sprint测试主要是针对集成和回归的版本测试。需要强调的是这里提供的敏捷测试流程只是作为参考的模板，并不是一成不变的。读者可以根据自己组织和项目的特点对流程进行剪裁，定制出适合自己项目环境的流程。

跨Sprint敏捷测试流程一般应用在版本发布级别，主要适用于多Scrum团队和多Sprint下环境下统一协作的情况。跨Sprint敏捷测试流程需要对不同Scrum团队和不同Sprint的交付物进行集成和回归验证测试，最终才能达到预发布的状态。

在集成的过程，主要还是依靠CI/CD流程，同时辅助人工探索式测试来实现。CI/CD为多个Scrum团队的候选应用版本部署到系统或发布集成环境中，同时会运行回归测试，验证这些应用集成没有问题并且通过人工的探索式测试后就能达到预发布的状态。

四、敏捷测试实践转变

（1）需求到配置库。
这个环节是需求相关的环节，我们针对需求主要采用ATDD或者BDD的实践进行活动，同时也要考虑关于可用性的调研，可以通过低保真原型向最终用户收集反馈。该环节的赋能者是BDD框架、ATDD框架，比如Cucumber、Specflow等。
（2）代码到开发环境。
这个环节是单元测试环节，我们针对代码主要进行单元测试TDD、静态代码分析、代码覆盖率分析等活动。该环节的赋能者是XUnit框架、Jacoco代码覆盖率分析、SonarQube静态代码扫描等。
（3）代码到Sprint测试环境。
这个环节是Sprint内测试环节，我们针对代码的功能性和非功能性进行测试，主要的质量活动包括功能测试、性能测试、安全测试等。该环节的赋能者是服务虚拟化、API和UI的测试自动化、组件和故事级别的性能测试等。
（4）代码到发布集成测试环境。
这个环节主要是跨Sprint的UAT测试环节，主要包括端到端联调测试、探索式测试、性能测试、可用性/易用性测试、安全测试等活动。该环节的赋能者是自动化测试框架、CI/CD流水线、安全漏洞扫描、用户体验测试、系统级别的性能测试等。
（5）代码到生产环境。

这个环节主要是上线后环节，包括的质量活动如A/B测试、生产环境测试、混沌工程（Chaos Engineering）等。该环节的赋能者是自动化测试框架、生产监控工具包括APM等。


来源：《敏捷之道》——敏捷项目下的传统测试转型之旅--文/陈晓鹏

发表评论
通过审核后显示您的意见