当前位置：首页 > news >正文

敏捷测试文化的转变

news 来源：原创 2025/5/13 22:14:19

敏捷文化是敏捷测试转型的基础，只有具备敏捷文化的氛围，对组织架构、流程和相关测试实践的调整才能起作用。在前面的敏捷测试定义中，敏捷测试是遵从敏捷软件开发原则的一种测试实践，这意味着敏捷的价值观。

此外，从传统测试到敏捷测试的文化转变还包括组织文化转变、管理文化转变，以及在转变过程中可能遇到的障碍等。

一、组织文化的转变

小心变成“质量警察

在传统测试中，测试部门或测试团队是产品发布到产品生产前的最后一道屏障，因此，测试人员在项目中充当了“质量警察”的角色。在项目测试过程中，项目管理办公室或项目经理会咨询测试经理的意见，判断产品是否达到了上线的条件和要求，测试经理的反馈将影响项目管理层的上线决策。

而在敏捷测试中，测试人员不再被赋予这样的权力和职责，项目的发布与否也不再依赖某个人或某个组织，而是整个敏捷团队的决策。因此，测试人员必须转变思想，不要抱有测试人员是决定项目上线的判官这一心理，而是要从实际出发，根据敏捷测试的实践要求进行测试。

保持可持续的速度，而不是在项目的最后阶段进行快速激烈的测试

在传统项目中，测试发生在产品上线前的最后阶段，所以经常看到测试人员在上线前的一段时间非常繁忙，压力很大，甚至经常加班完成测试任务，而组织也默认这种加班文化，认为牺牲项目成员的休息时间来“死守”上线时间也无可厚非。可想而知，测试人员在极度疲惫的情况下，测出来的质量是无法保证的。

而在敏捷测试中，长期加班的文化是不被认可的。在敏捷中，判断团队能否加班的原则之一就是团队能否保持可持续的速度。如果只是偶尔加班处理紧急的事情，不影响整体的交付速度，那无伤大雅；而如果是长期加班使测试人员处于一种疲劳、沮丧、情绪低落的状态，如何还能保证可持续的速度呢？因此，传统模式的最后阶段被切分为不同的迭代片段，并且融入每次的sprint中，这样才能使测试工作趋于平均，从而保证可持续的速度。

合作伙伴式的客户关系

在传统的测试中，客户与测试人员是甲方与乙方的关系，很多测试人员都不愿意主动和客户进行交流，遇到需要澄清的问题不是直接找客户咨询，而是找开发人员或业务分析师，然后再让开发人员或业务分析师与客户沟通，从而失去了掌握第一手资料的机会，也增加了沟通成本。

而敏捷测试中，客户与测试人员不再是甲方与己方的关系，而是合作伙伴关系，大家拥有共同的目标，那就是使项目获得成功，所以客户会更频繁地参与项目各方面，了解客户需要什么、关注什么、担心什么，从而更好地开展测试工作。

二、管理文化的转变

每个团队都有能力做出决策

在传统测试中，决策往往取决于项目中的少数人，如项目经理或项目管理办公室(PMO)等，但是在敏捷团队中，已经没有项目经理或项目管理办公室这类角色，那么谁来做决策呢？答案是团队。

每个团队都有能力做出决策，这个能力有两层含义：一是外部相关，是指组织或公司需要赋权给团队，让团队有权利自己做出相关的决策;二是内部相关，是指团队必须有能力判断并做出正确的决策。

提倡免责文化

在传统测试中，我们经常会看到版本上线后的回顾会变成了追责会，会议的重点是讨论上线后的缺陷应该谁来负责？需求部门把责任推给开发部门，开发部门把责任推给测试部门，测试部门把责任推给需求部门，大家不是在讨论下次如何避免再出现同样的问题而是想方设法把责任推给别人。出现这种情况的原因在于很多组织的绩效考核都与上线后的缺陷挂钩，大家为了各自的利益而拼命“甩锅”。

无论是敏捷还是 DevOps 领域都提倡免责文化，也就是不把犯错误和绩效考核挂钩，原因在于敏捷是基于经验的，在敏捷的环境中，我们需要保持不断创新、不断尝试的勇气，而创新尝试具有很高的风险。在这种情况下，如果还是把失败与绩效挂钩，就会打击尝试者的积极性，久而久之，大家宁愿墨守成规，也不愿意尝试创新，整个组织或项目最终将失去不断自我改进的活力。所以，在敏捷中不但应该不怕犯错，而且应该尽早犯错以便及时调整后续策略。

管理层需要具备敏捷知识

有些领导觉得敏捷是员工应该学习的内容，因为他们是具体工作的人，而管理层没必要学习，这其实是一个错误的想法。Richard Knaster和 Dean Leffngwell 在《SAFe4.0 精粹：运用规模化敏捷框架实现精益软件与系统工程》中提道：“企业的领导者必须拥抱'精益-敏捷’思维。如果领导者只是通过语言而不是自身的行动来支持'精益-敏捷’思维，人们很快就会认识到他们不是在全心全意地推动变革。他们必须知晓方法,强调终身学习，需要用新的行为践行这些价值观、原则和实践。所以在规模化敏捷 SAFe 的系列培训课程中，专门有一门课程叫作 LeadingSAFe,主要对管理层和主管级别以上的领导进行培训。”管理层必须知道与敏捷过程相关的度量标准，如Scrum 中使用Sprint和 Release 燃尽图跟踪用户故事的完成情况，同时还需要通过分享他们的业务观点来鼓励团队将投资回报率(ROI)最大化。

总之，管理层如果具备敏捷知识，并且积极支持和践行敏捷，那么对敏捷测试的转型将会带来非常大的帮助，也会大大提高敏捷测试转型的成功率。

三、文化转型的障碍及解决办法

任何转型都不是一帆风顺的，可以预料，在转型实施的过程中一定会碰到各种障碍以下是部分可能存在的障碍和解决方法。

组织变化带来的恐惧

在敏捷环境中，组织架构不再与传统的职能型部门架构一样，测试人员也不再属于测试部门，这迫使测试人员离开了熟悉的组织环境。新环境会让测试人员感到陌生，从而令他们感到恐惧，例如，以前测试人员碰到问题可以直接向测试部门经理反映，很多事情测试部门经理会帮忙协调和处理,而在新环境中，没有这样的角色可以为测试人员提供帮助，很多事情可能需要他们自己协调团队解决，这种改变会让测试人员无所适从，对未来感到害怕，从而迷失自我。

要移除这个障碍有以下两种解决方法。一是在Sprint 回顾会上正面讨论测试人员的恐惧，团队集思广益，共同解决。要让测试人员知道，如果遇到问题，团队一定不会袖手旁观，从而消除测试人员的恐惧感。二是组织需要规划和制订属于测试人员的职业发展路线，让测试人员能够清晰地知道未来的发展方向，减少其对未来的迷茫感。

缺乏对敏捷概念的基本认识

许多测试人员没有接触过敏捷，也没有参加过相应的敏捷知识培训。不少企业在安排敏捷培训时往往会重点安排开发人员参加，而忽略了测试人员。他们天真地认为敏捷开发，顾名思义，是开发人员的事，测试人员只需和以前一样编写测试用例、点击鼠标执行测试即可。所以，当突然被安排了某个敏捷项目时，一方面因为自身对敏捷流程不熟悉，另一方面项目也没有指南可以帮助克服角色之间的文化差异,测试人员最终无法跟上整个项目的开发节奏和进度。

要移除这些障碍可以参考以下两种解决方法：一为测试人员提供敏捷相关知识的培训，让测试人员至少知道什么是敏捷测试，以及敏捷开发和传统开发的差异等基础知识，一旦测试人员了解相关知识，就会消除恐惧，并且还会逐渐适应这样的环境；二是敏捷导师在辅导团队的时候，需要这些没有敏捷测试经验人员多加关注，耐心的引导和教导他们，让他们能够在相对宽松的实战项目中逐渐进步，提升敏捷知识。

无法满足更高的技能要求

在传统职能型部门，测试人员的任务相对单一，只需要做好相关的测试工作即可、而在敏捷跨职能团队中，测试人员的任务并不局限在测试范畴，还有可能要处理任何对团队有益、能帮助团队更快速交付的活动，如帮助开发人员与业务部门澄清需求、参加开发人员的代码评审等。

这些工作都需要测试人员拥有除测试技能外的更广泛的技能，如代码阅读能力、需求沟通能力等，对测试人员的综合能力要求变得更高了。而这些对于以前只有单一技能的测试人员来说，在短时间内想要提高的难度很大。

要移除这个障碍可以参考如下两种解决方法。一是可以成立测试实践社区，让测试员能找到组织，在组织中，大家互相学习，共同进步，从而提升测试人员的技能；二是对于部分技能要求较高的岗位，可以考虑从外部招聘合适的人员来补充团队力量。

总体来说，企业需要为团队的测试人员给予更多的培训和指导，帮助他们尽快学习敏捷相关知识，克服因为不懂敏捷而带来的恐惧，尽快完成角色转换，以适应项目需要。

阅读后若有收获，不吝关注，分享，在看等操作！！！