敏捷项目下的传统测试转型之旅 | IDCF

来源：DevOps社区Meetup，本文曾发表于“《测试技术与质量管理》季刊第19期”

作者：陈晓鹏。测试、敏捷及DevOps专家。德勤管理咨询系统集成业务线测试负责人，中国商业联合会互联网委员会智库专家，ISO29119软件测试国际标准评审组专家。19年IT领域测试相关工作经验，超过13年在IBM、埃森哲、德勤等国际顶尖IT咨询及世界五百强公司工作。擅长测试咨询与落地、项目管理、测试自动化及敏捷测试、DevOps等相关领域。

编辑：墨香

摘要：随着这几年业务的快速变化以及敏捷开发方法的流行，越来越多的组织都采用敏捷模式进行项目开发。而这种时间极短且频繁的迭代发布让习惯于在传统瀑布模式开发下的测试人员感到应对吃力，心力交瘁。如果这样的状态持续下去，则对项目将是一个极大的风险。如何才能改变这种现状，让测试人员能更加顺利的在敏捷项目下面进行工作，既能保证进度又能保证质量呢？本文提出敏捷测试转型模型，从文化、组织、流程、实践等各个方面进行阐述，为传统测试转型敏捷测试带来指导意义。

一、传统测试在敏捷环境下面临的挑战

敏捷开发模式和传统瀑布开发模式有着不小的区别。对于测试人员而言，如果我们在敏捷项目中还是使用传统瀑布开发模式的测试方法和实践，将会碰到来自四个方面的挑战：

• 时间极短

敏捷强调快速，一般一个迭代的周期为2-4周，在这么短的时间周期内留给测试的时间寥寥无几。测试人员如何做到既能完成测试任务同时还要保证质量，将是一个巨大的挑战。

• 文档极少

敏捷的特点是轻文档，意味着测试人员能看到的文档信息内容不会太详细。因此在少文档的情况下如何进行测试用例设计以及判断测试执行是否通过，将是测试人员面临的又一个棘手问题。

• 变更极频

敏捷强调拥抱变化，所以在软件开发过程中会存在不断变更的可能。变更不但意味着在测试环境中可能存在多套测试版本，更有可能使得之前已经做了一半的测试工作心血付诸东流。

• 资源极缺

敏捷提倡跨职能团队，所以淡化专职测试人员角色。在一个敏捷团队中，往往一个7-9人的团队只有1个功能测试人员。在测试人员极少的情况下如何能保障整个项目按时按质完成，已经成为令人头痛的障碍。

二、敏捷环境下应采用敏捷测试

既然在敏捷环境下不能再按照传统的测试方式执行，那么就需要有一套适合敏捷环境的新的测试实践，我们称之为敏捷测试。关于敏捷测试的定义，并没有官方统一的标准。以下是维基百科对敏捷测试的定义：

“敏捷测试是遵从敏捷软件开发原则的软件测试实践。敏捷测试包括跨功能敏捷团队的所有成员，以及测试人员提供的特殊专业知识，以确保可持续的速度频繁地交付客户所需的业务价值。”

从定义中我们都可以看出敏捷测试主要包含的核心内涵有三点：

• 敏捷测试遵从敏捷开发的原则，强调遵守。所以敏捷价值观和敏捷宣言遵循的12原则同样适用在敏捷测试中。
• 测试被包含在整体开发流程中，强调融合。在敏捷开发过程中不再像传统项目那样有开发阶段和测试阶段之分，而是把开发和测试作为一个整体过程来看待。
• 跨职能团队，强调协作。跨职能意味着团队需要具备不同专业技能的人才共同组成，彼此之间互相协作、互相帮助，发挥每个人在团队中的优势，从而使得团队绩效最大化。

三、往敏捷测试转型的四个要素

在前面的讨论中我们已经知道传统测试需要进行转型才能应对这种快速迭代的工作模式。但是，接下来的问题是传统测试到底需要在哪些领域做出改变呢？下面给出一个可以指导我们行动的敏捷测试转型模型，如图1所示。

图1 敏捷测试转型模型

让我们来进一步看看模型涉及到的四个要素：

3.1 文化

首先，文化转变是敏捷转型的基础，脱离了文化，敏捷转型就像无根之木、无源之水，最终可能将变成“伪敏捷”。所以文化转变，具体到人的意识和思想观的转变，是整个敏捷测试转型体系中最重要的要素。

3.2 组织

其次，在整个转型过程离不开“组织”，组织结构需要和未来的目标相匹配才能确保转型成功，所以转型一定会涉及到组织这个要素，而且还会对敏捷测试转型成功与否产生重大的影响，因此在模型中我们可以看到组织是在文化之上的又一个重要要素。

3.3 流程

再次，组织涉及到的是人，而人需要改变其做事的方式和过程，也就是工作流程。在敏捷框架下的流程和传统测试的流程有非常大的不同，这就需要我们对测试角色和职责、测试流程等方面进行重新调整，以达到适应敏捷这种快速迭代的开发模式特点。

3.4 实践

最后，我们知道敏捷有许多不同的实践，这些实践中很多都和测试有关，比如测试驱动开发TDD、行为驱动开发BDD、验收测试驱动开发ATDD等。因此我们在测试中可以借鉴和融合这些实践，从而使我们能更加有信心的进行敏捷测试转型。

四、敏捷测试文化转变

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

4.1 组织文化转变

• 小心变成质量警察

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

• 可持续的速度而不是在项目尾段快速激烈的测试

在敏捷测试中是不认可加班文化的。判断团队能否加班的一条原则就是团队能否保持可持续的速度。如果只是偶尔加下班处理紧急的事情，不影响整体的交付速度，那无伤大雅；而如果是长期的加班使得测试人员处于一种疲劳、沮丧、情绪低落的状态，那就说明开发过程不可持续，需要做改变。

• 合作伙伴式的客户关系

在敏捷测试中，客户与测试人员不再是甲乙方关系，而是合作伙伴的关系，大家有同一个目标，那就是使项目成功。所以客户会更频繁的参与到项目的各个方面，而测试人员也需要更主动的与客户进行沟通，了解客户需要什么、关注什么、担心什么，从而能更好的帮助测试工作。

4.2 管理文化转变

• 每个团队都有能力做出决定

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

• 提倡免责文化

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

• 管理层需要具备敏捷知识

有些管理层领导觉得敏捷是下面的人应该去学习的，因为他们是具体干活的，而管理层则没必要学习敏捷知识。这其实是一个错误的想法。在Richard Knaster和Dean Leffingwell的著作《SAFe4.0精粹》一书中说到：企业的领导者必须拥抱精益-敏捷思维。如果领导者只是通过语言而不是他们自身的行动来支持敏捷，人们很快就会认识到他不是全心全意在推动变革。他们必须知晓方法，强调终身学习，需要用新的行为践行这些价值观、原则和实践。

五、敏捷测试组织转变

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

而在敏捷环境中，组织架构需要转变成为跨职能团队，如图2所示，也就是在团队里面会有不同技能的人员，可能包括业务分析、开发、测试，架构师、甚至是DBA等角色。在这种模式下，团队的沟通会变得更加直接和有效，成员之间无需经过间接的第三方进行沟通传达，而是经常可以直接面对面进行沟通，从而大大提高了沟通的效率。

图2 敏捷测试组织架构转变

组织架构调整后可能会出现测试人员的归属感问题。因为原来的测试部门没有了，测试人员担心他们的个人职业发展和技能培养由谁来关心？我们可以考虑成立测试实践社区（Testing Communities of Practice）。

在SAFe中是如此定义实践社区CoP的：

实践社区是一个由团队成员和其他专家组成的非正式团体，他们在一个项目群或企业环境中活动，并且拥有在一个或多个相关领域分享实践知识的使命。

由定义可知，虽然CoP不是一个正式的团体组织，无法承担测试人员管理的职责，但是至少可以让测试人员有一个“精神乐园”作为寄托，可以在里面学习与分享，减少测试人员的迷茫感。

六、敏捷测试流程转变

6.1 敏捷测试类型

敏捷有不同层次的工件，而在这些不同的敏捷工件中，我们需要的测试范围和测试策略也不一样：

• 代码：在Sprint层级中，我们需要对代码进行质量扫描和单元测试，主要测试独立的代码单元是否正确。这个测试在单个Sprint内完成，不会跨Sprint。
• 故事：在Sprint层级中，我们主要的测试对象是用户故事。我们需要根据故事的验收标准进行测试，这个测试是在Sprint迭代过程中执行的，而且不会跨Sprint。
• 特性：在版本发布层级中，我们的测试对象是特性，主要是测试一些故事之间如何协同工作向用户交付更大的价值。这个测试有些可以在Sprint内完成，有些需要跨Sprint才能完成。
• 史诗：在版本发布层级中，我们测的对象是史诗，主要是跨多个特性的核心业务流程，通常是端到端的集成测试。这个测试通常都是要跨Sprint才能完成。

除此之外，对于非功能性的性能测试，无论是用户故事、特性还是史诗，都需要考虑性能测试。在敏捷中，性能测试也需要提前并且分迭代来执行，而不能只在最后阶段再考虑。通过上面的介绍，我们知道了对于不同级别的敏捷工件使用不同的测试策略有助于将测试集中在交付的完整功能集上，从单元测试级别粒度一直到端到端业务流，如表1所示。

表1 敏捷测试中不同级别的测试类型

注：

• L1级别主要是针对单元组件模块级别进行的性能测试；
• L2级别主要是针对用户故事级别进行的性能测试；
• L3级别主要是针对整个版本端到端级别进行的性能测试。

我们从上表中可以看到，有些测试类型是在Sprint迭代内进行的，而有些测试类型是需要跨Sprint来执行的，因此我们可以简单的把敏捷测试分成两大类的测试类型：一类是Sprint内测试（In-Sprint Testing）；另一类是跨Sprint测试（Cross-Sprint Testing），如下图3所示。

图3 Sprint中的敏捷测试类型

6.2 敏捷测试流程

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

图4 敏捷测试流程

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

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

七、敏捷测试实践转变

在讨论完文化、组织和流程后，下面我们继续讨论最后一个实践部分。首先我们可以按照开发过程中代码推进路径的先后顺序分成不同的环节：

• 需求到配置库
• 代码到开发环境
• 代码到Sprint测试环境
• 代码到集成/发布测试环境
• 代码到生产环境

在这些环节中，代码从一个环节传到下一个环节，它的质量应该会好些；再传到再下一个环节，它的质量应该又更好些......一直到生产环节，用户最终可以接收到一个质量可靠的产品。在这个过程中，这些环节就好像安置了一个“质量漏斗”，代码从一开始的输入到最后的走向市场，经过质量漏斗的层层检验后，质量越来越好，直到最后代码被部署到生产环境推向市场。在生产上线后，还需要监控市场的接受度，收集并且确认来自用户的反馈，把反馈推给内部的团队作为新的输入，以此就建立了一个反馈环，如图5所示。

图5 敏捷测试实践框架

在质量漏斗中内置了不同环节的质量活动和赋能者来驱使质量的不断提升。这些质量活动和赋能者不仅仅只在测试中才有，而是贯穿到整个开发过程中，这也是“质量内建”（Quality Build-in）的理念。

我们来看看不同的环节有什么样的质量活动和赋能者在其中：

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

最后我们再看不同环节的测试工作量分布。在代码向后推进的不同的环节中，我们的测试工作量是逐步减少的，这个也是和测试金字塔的理念一致的。

八、结语

让我们再来回顾本文一开始提到的四个挑战：

• 通过敏捷测试流程使得测试过程与敏捷迭代一致，解决了测试时间短的问题；
• 通过合作伙伴式的客户关系文化转变，使得我们不再需要描写繁杂的需求文档，我们通过与客户频繁沟通了解客户的真正需要；
• 通过组织架构向跨职能团队调整，质量应由团队保障，解决了专职测试资源少的问题；
• 通过敏捷测试实践的自动化测试与持续集成，缩减反馈周期，使得在变更频繁的情况下也能很好的保证质量。
  

敏捷测试转型不是一蹴而就的事情，需要组织持续不断的坚持才能成功。敏捷测试转型过程中也没有一套放之四海而皆准的标准，所以转型者也需要按照敏捷的方式小步进行、回顾评审、重新调整、再小步进行……相信通过这样的方式成功一定会在不远之处等着我们。

参考文献

• [1] SAFe4.0精粹 电子工业出版社 (美)理查德·克纳斯特,(美)迪恩·莱芬韦尔著
• [2] Scrum精髓 清华大学出版社 （美）凯恩鲁本著
• [3] 维基百科

本文作者敏捷测试专家陈晓鹏老师的课程【IDCF训练营-敏捷测试方法与实践训练营】，6个专题，450分钟，详细讨论传统测试如何敏捷转型，带给您最新的敏捷测试知识。限时团购优惠，识别下图二维码即可拼团学习，赶快加入吧~