下载掌阅APP，畅读海量书库
立即打开
前面的内容讨论了传统测试在敏捷环境中需要进行转型，才能应对快速迭代的工作模式。但是，传统测试究竟需要在哪些领域做出转变呢？我们知道，转型并不是一件简单的事情，不是简简单单在某一方面做些改变就能成功的。转型这个词本身是指事物的结构形态、运转模型和人们观念的根本性转变过程，而根本性转变是从内到外的，不只是做事方式的转变，还涉及意识、思想观念等方面的转变。传统测试往敏捷测试转型亦是如此，不仅“形”要转变，更重要的是“神”也要转变，而这个“神”，指的就是文化，具体来说，就是整个团队需要具备敏捷文化，这将会在3.2节中具体讨论。
当然，仅文化转变还不够，除了文化，组织架构、流程、实践等方面也要做出相应的转变，这些都将与传统测试有很大不同，如图3-1所示为一个可以指导行动的敏捷测试转型模型。
图3-1 敏捷测试转型模型
值得注意的是，除文化外，上述敏捷测试转型模型还涉及3个要素：组织、流程和实践。其实，在质量领域也有一个非常著名的模型，叫作“质量铁三角”，是指影响质量的3个要素：组织（人）、流程、技术（工具）。可以看出，敏捷测试转型模型和质量铁三角考虑的领域不谋而合。
接下来进一步讲解这个模型，先来介绍模型涉及的4个要素。
（1）文化。
正如上文所述，文化转变是敏捷测试转型的基础，脱离了文化，敏捷测试转型就像无根之木、无源之水，最终可能变成“伪敏捷”。文化转变可具体到人的意识和思想观念的转变，是整个敏捷测试转型体系中最重要的要素。但是，转变人的思想和意识是一件非常困难的事情，是一个漫长的过程，很难通过开几个宣讲会、做几次培训“洗脑”就实现，所以文化转变在敏捷测试转型模型中既是最重要的，也是最困难的要素。
（2）组织。
整个转型过程都离不开组织，只有组织结构与未来的目标匹配，才能确保转型成功，所以转型一定会涉及组织这个要素。组织非常重要，其会对敏捷测试转型的成功产生重大的影响。因此，在图3-1的敏捷测试转型模型中，组织是在文化要素之上的一个要素。敏捷本身强调的是跨职能团队，因此传统的职能型组织结构将是实施敏捷时面临的一个较大阻碍，我们需要做出改变，以更好地适应敏捷。
（3）流程。
组织涉及的是人，而人需要改变做事的方式和过程，也就是工作流程。在敏捷模式下的流程和传统测试的流程存在较大不同，这就需要对测试角色、职责、流程等进行调整，以适应敏捷的快速迭代的开发特点。
（4）实践。
除了文化、组织和流程，还有一个要素是实践，也就是在技术层面是否有落地的手段。在传统测试中，自动化测试并不是不可或缺的，但是在敏捷环境中，自动化测试被高度推荐，并且扮演着非常重要的角色。此外，敏捷还有许多不同的实践，这些实践很多都与测试有关，如测试驱动开发（TDD）、行为驱动开发（BDD）、验收测试驱动开发（ATDD）等。我们在测试时可以借鉴和采纳这些好的实践，在测试过程中充分利用这些已经被证明有效的实践，从而更加自信地进行敏捷测试转型。
接下来讨论模型的形状。为什么把文化放在敏捷测试转型模型的底层，上层是组织，再上层是流程，顶部是实践？大家看到的敏捷测试转型模型是一个三角形的形状，很容易联想到敏捷大师Mike Cohn提出的测试金字塔（详细内容见5.2节）。测试金字塔分为3层，底层是单元测试，中间层是API服务层测试，顶层是UI界面测试。底层的面积占三角形总面积的比例最大，这说明需要把较多的精力放在单元测试上。其实，敏捷测试转型模型和测试金字塔的表达原理是一样的。文化是整个敏捷测试转型中最重要也是最困难的要素，所以它也是我们需要花费最多精力和给予最多关注的要素。同理，实践与其他要素相比是相对容易实现的，所以我们把它放在了顶部，最终形成了图3-1所示的金字塔形状。
在讨论完形状后，再来分析实施重要程度这个维度。如图3-1所示，在敏捷测试转型模型中，对于文化、组织、流程和实践这4个要素，如果从实施的重要程度来看，重要性排序应该是文化＞组织＞流程＞实践。这带给我们的启示是，在敏捷测试转型中，切忌抛弃文化转变而只关注后面的流程或实践，并不是团队照搬了Scrum的流程就能说这个团队已经是敏捷的了，这是很多组织或团队对敏捷的误解。以下是我亲身经历的一个例子。
我曾经给一家企业做过短暂的测试咨询，当时这家企业宣称其项目是按敏捷Scrum的模式进行开发的，我在访谈该项目测试经理时曾询问：“你们项目的一些问题有没有在Sprint回顾会上讨论过？”测试经理回答：“以前我们是有Sprint回顾会的，但是后来发现在会上大家都不怎么发言，就觉得是在浪费时间，于是就取消了。”我又追问：“为什么大家在会上都不发言呢？”测试经理回答：“大家觉得提的问题很多时候都解决不了，提了也没用；而且老板有时候也会参加，大家就不想说话了。”
在这个例子中，尽管项目照搬了敏捷Scrum框架，但是至少在Sprint回顾会这一部分并没有做好，而且老板参会就无人敢发言，其根源在于整个组织缺乏免责文化，大家都不敢说，不敢提意见，怕说多错多，久而久之，Sprint回顾会就流于形式而不产生效果了。这是一个典型的忽视文化转变而只注重流程转变的例子，其结果是项目一定无法收获敏捷带来的好处。
再来分析另外一个维度，也就是实施困难程度。如图3-1所示，如果从实施困难程度来看，其排序应该是文化＞组织＞流程＞实践。与前面的观点相同，采纳一个新流程、新实践并不难，例如，我们花费几天时间就能搭建出一条CI/CD部署流水线，但若要转变人的思想观念，或者转变整个组织的文化，则并非一朝一夕就可实现，而是需要持续不断地努力。虽然这一转变过程很艰难，但如果在这点上不做改变，那么转型极大概率会以失败告终。
还有一个备受关注且非常有必要讨论的内容就是实施顺序。依照敏捷测试转型模型，到底是采用“自顶向下”的顺序，还是采用“自底向上”的顺序实施呢？在这一点上没有严格的标准和建议，因为每个企业和组织的情况都不一样，而不一样的环境可能会影响实施策略的选择，比如，某组织的老板魄力很大、很强势，而且也非常支持敏捷测试转型，那么就可以实施“自底向上”的策略。而如果某组织的老板相对比较保守，是希望能慢慢摸索和试验，等看到一些成果后再做决定的稳健型风格，那么就可以采取“自顶向下”的策略，通过先实施一些小的“Quick-Win”的实践，得到快速反馈和获得收益后再大力推广。还有一种策略就是双头并进，即“自底向上”和“自顶向下”相结合。在组织的基因与敏捷理念比较吻合、敏捷基础比较好，同时也具备一些能够实施自动化测试等敏捷实践的资源时，比较适合使用这种策略。所以，实施顺序并没有唯一标准，每个企业需要根据实际情况制订适合自己的最佳转型实施策略。
3.1节整体介绍了敏捷测试转型模型，接下来对该模型进行深入介绍。首先，讨论文化的转变。
敏捷文化是敏捷测试转型的基础，只有具备敏捷文化的氛围，对组织架构、流程和相关测试实践的调整才能起作用。在前面的敏捷测试定义中，敏捷测试是遵从敏捷软件开发原则的一种测试实践，这意味着敏捷的价值观、敏捷软件开发宣言和敏捷宣言遵循的12条原则等同样适用于敏捷测试。此外，从传统测试到敏捷测试的文化转变还包括组织文化转变、管理文化转变，以及在转变过程中可能遇到的障碍等。
在传统测试中，测试部门或测试团队是产品发布到产品生产前的最后一道屏障，因此，测试人员在项目中充当了“质量警察”的角色。在项目测试过程中，项目管理办公室或项目经理会咨询测试经理的意见，判断产品是否达到了上线的条件和要求。测试经理的反馈将影响项目管理层的上线决策。
而在敏捷测试中，测试人员不再被赋予这样的权力和职责，项目的发布与否也不再依赖某个人或某个组织，而是整个敏捷团队的决策。因此，测试人员必须转变思想，不要抱有测试人员是决定项目上线的判官这一心理，而是要从实际出发，根据敏捷测试的实践要求进行测试。
在传统项目中，测试发生在产品上线前的最后阶段，所以经常看到测试人员在上线前的一段时间非常繁忙，压力很大，甚至经常加班完成测试任务，而组织也默认这种加班文化，认为牺牲项目成员的休息时间来“死守”上线时间也无可厚非。可想而知，测试人员在极度疲惫的情况下，测出来的质量是无法保证的。
而在敏捷测试中，长期加班的文化是不被认可的。在敏捷中，判断团队能否加班的原则之一就是团队能否保持可持续的速度。如果只是偶尔加班处理紧急的事情，不影响整体的交付速度，那无伤大雅；而如果是长期加班使测试人员处于一种疲劳、沮丧、情绪低落的状态，如何还能保证可持续的速度呢？因此，传统模式最后阶段的测试需要被切分成不同的迭代片段，并且融入每次Sprint中，这样才能使整个测试工作趋于平均，从而保证可持续的速度。
在传统测试中，客户与测试人员是甲方与乙方的关系，因此，很多测试人员都不愿意主动和客户沟通交流，遇到需要澄清的问题不是直接找客户咨询，而是找开发人员或业务分析师（BA）沟通，然后再让开发人员或业务分析师与客户沟通，从而失去了掌握第一手资料的机会，也增加了沟通成本。
而在敏捷测试中，客户与测试人员不再是甲方与乙方的关系，而是合作伙伴关系，大家拥有共同的目标，那就是使项目获得成功，所以客户会更频繁地参与项目各方面，而测试人员也需要更主动地与客户沟通，了解客户需要什么、关注什么、担心什么，从而更好地开展测试工作。
在传统测试中，决策往往取决于项目中的少数人，如项目经理或项目管理办公室（PMO）等，但是在敏捷团队中，已经没有项目经理或项目管理办公室这类角色，那么谁来做决策呢？答案是团队。
每个团队都有能力做出决策，这个能力有两层含义：一是外部相关，是指组织或公司需要赋权给团队，让团队有权利自己做出相关的决策；二是内部相关，是指团队必须有能力判断并做出正确的决策。
在传统测试中，我们经常会看到版本上线后的回顾会变成了追责会，会议的重点是讨论上线后的缺陷应该谁来负责？需求部门把责任推给开发部门，开发部门把责任推给测试部门，测试部门把责任推给需求部门，大家不是在讨论下次如何避免再出现同样的问题，而是想方设法把责任推给别人。出现这种情况的原因在于很多组织的绩效考核都与上线后的缺陷挂钩，大家为了各自的利益而拼命“甩锅”。
无论是敏捷还是DevOps领域都提倡免责文化，也就是不把犯错误和绩效考核挂钩，原因在于敏捷是基于经验的，在敏捷的环境中，我们需要保持不断创新、不断尝试的勇气，而创新尝试具有很高的风险。在这种情况下，如果还是把失败与绩效挂钩，就会打击尝试者的积极性，久而久之，大家宁愿墨守成规，也不愿意尝试创新，整个组织或项目最终将失去不断自我改进的活力。所以，在敏捷中不但应该不怕犯错，而且应该尽早犯错，以便及时调整后续策略。
有些领导觉得敏捷是员工应该学习的内容，因为他们是具体工作的人，而管理层没必要学习，这其实是一个错误的想法。Richard Knaster和Dean Leffingwell在《SAFe4.0精粹：运用规模化敏捷框架实现精益软件与系统工程》中提道：“企业的领导者必须拥抱‘精益-敏捷’思维。如果领导者只是通过语言而不是自身的行动来支持‘精益-敏捷’思维，人们很快就会认识到他们不是在全心全意地推动变革。他们必须知晓方法，强调终身学习，需要用新的行为践行这些价值观、原则和实践。所以在规模化敏捷SAFe的系列培训课程中，专门有一门课程叫作Leading SAFe，主要对管理层和主管级别以上的领导进行培训。”
管理层必须知道与敏捷过程相关的度量标准，如Scrum中使用Sprint和Release燃尽图跟踪用户故事的完成情况，同时还需要通过分享他们的业务观点来鼓励团队将投资回报率（ROI）最大化。总之，管理层如果具备敏捷知识，并且积极支持和践行敏捷，那么对敏捷测试的转型将会带来非常大的帮助，也会大大提高敏捷测试转型的成功率。
任何转型都不是一帆风顺的，可以预料，在转型实施的过程中一定会碰到各种障碍，以下是部分可能存在的障碍和解决方法。
在敏捷环境中，组织架构不再与传统的职能型部门架构一样，测试人员也不再属于测试部门，这迫使测试人员离开了熟悉的组织环境。新环境会让测试人员感到陌生，从而令他们感到恐惧，例如，以前测试人员碰到问题可以直接向测试部门经理反映，很多事情测试部门经理会帮忙协调和处理，而在新环境中，没有这样的角色可以为测试人员提供帮助，很多事情可能需要他们自己协调团队解决，这种改变会让测试人员无所适从，对未来感到害怕，从而迷失自我。
要移除这个障碍有以下两种解决方法。一是在Sprint回顾会上正面讨论测试人员的恐惧，团队集思广益，共同解决。要让测试人员知道，如果遇到问题，团队一定不会袖手旁观，从而消除测试人员的恐惧感。二是组织需要规划和制订属于测试人员的职业发展路线，让测试人员能够清晰地知道未来的发展方向，减少其对未来的迷茫感。
许多测试人员没有接触过敏捷，也没有参加过相应的敏捷知识培训。不少企业在安排敏捷培训时往往会重点安排开发人员参加，而忽略了测试人员。他们天真地认为敏捷开发，顾名思义，是开发人员的事，测试人员只需和以前一样编写测试用例、点击鼠标执行测试即可。所以，当突然被安排了某个敏捷项目时，一方面因为自身对敏捷流程不熟悉，另一方面项目也没有指南可以帮助克服角色之间的文化差异，测试人员最终无法跟上整个项目的开发节奏和进度。
要移除这个障碍可以参考以下两种解决方法：一是为测试人员提供敏捷相关知识的培训，让测试人员至少了解什么是敏捷，以及敏捷开发和传统开发的差异等基础知识，一旦测试人员了解了相关知识，就会消除恐惧，并且逐渐适应这样的环境；二是Scrum Master或敏捷教练在辅导团队的时候，需要对这些没有敏捷经验的测试人员多加关注，耐心地引导和教导他们，让他们能够在相对宽松的实战项目中逐渐进步，提升敏捷知识。
在传统职能型部门，测试人员的任务相对单一，只需要做好相关的测试工作即可。而在敏捷跨职能团队中，测试人员的任务并不局限在测试范畴，还有可能要处理任何对团队有益、能帮助团队更快速交付的活动，如帮助开发人员与业务部门澄清需求、参加开发人员的代码评审等。这些工作都需要测试人员拥有除测试技能外的更广泛的技能，如代码阅读能力、需求沟通能力等，对测试人员的综合能力要求变得更高了。而这些对于以前只有单一技能的测试人员来说，在短时间内想要提高的难度很大。
要移除这个障碍可以参考如下两种解决方法。一是可以成立测试实践社区，让测试人员能找到组织，在组织中，大家互相学习、共同进步，从而提升测试人员的技能；二是对于部分技能要求较高的岗位，可以考虑从外部招聘合适的人员来补充团队力量。
总体来说，企业需要为团队的测试人员给予更多的培训和指导，帮助他们尽快学习敏捷相关知识，克服因为不懂敏捷而带来的恐惧，尽快完成角色转换，以适应项目需要。
传统的项目组织基于职能型组织架构，团队成员来自不同的职能部门，如需求部门、开发部门、测试部门等。团队成员的管理如绩效考核等，并不取决于项目，而是取决于各职能部门。这种组织架构带来的问题之一就是沟通模式成为“n”型模式，效率非常低，比如，部门A的成员X有问题需要部门B的成员Y协助，成员X不是直接与成员Y沟通，而是先向部门A的领导反映，然后由部门A的领导和部门B的领导沟通反馈，再由部门B的领导把信息转给部门B的成员Y。在这个过程中，信息绕了大半圈才传递给成员Y，沟通效率非常低。
而在敏捷环境中，组织架构需要转变为跨职能团队，如图3-2所示，也就是在团队中存在掌握不同技能的人员，可能包括业务分析师、开发人员、测试人员、架构师，甚至是数据管理员（DBA）等角色。这些角色会紧密地共同协作，同时，他们作为自组织的团队，拥有自主管理权和项目决策权，能够为整个项目负责。在这种模式下，团队沟通会变得更加直接且更加有效，成员之间无须经过第三方传话，而是面对面沟通，大大提高了沟通效率。
图3-2 组织架构转变
接下来再讨论关于组织架构调整后敏捷测试人员的归属感问题，这也是我在做完敏捷测试讲座后，测试人员经常问的问题。
在传统开发模式中，测试人员归属测试部门，测试人员的管理和绩效评定也由测试部门负责，这种模式的好处在于测试人员归属感强，因为掌握相同的技能，所以测试人员之间可以很好地学习和分享，但是在敏捷项目中，其缺点非常明显，整个团队的沟通和协作会受到很大阻碍，不适用于敏捷这种快速的交付方式。
在敏捷开发模式中，测试人员归属项目，测试人员的日常工作安排都是由项目自发组织安排的，绩效评定很可能由负责这个项目的领导管理，这种模式的好处是对于项目而言，整体的沟通和协作机制非常有效，能够提升整个团队的敏捷交付能力，其缺点在于测试人员对于未来比较焦虑，担心当前项目结束后该如何发展，以及他们的个人职业发展和技能培养谁来关心？
那么，有没有两全其美的方法呢？有两种解决方法可供参考。
一是在组织内成立卓越测试中心（Testing Center of Excellence）。卓越测试中心是测试人员的资源池，同时也肩负着培养测试人员技能和规划职业生涯发展的职责，它和以前的职能型测试部门的最大区别是当测试人员做项目时，卓越测试中心不能干涉和管理测试人员，测试人员完全属于项目；而当项目结束后，测试人员从项目中解放出来并回归卓越测试中心的资源池，在还没有安排下一个项目的时候，卓越测试中心应该负责对他们进行日常管理，同时也需要对他们进行技能培养和帮助他们实现技能提升，这样，测试人员无论是否在项目中，都有一种归属感，同时也不会影响项目的具体协作与交付。而在绩效评定的时候，应由卓越测试中心牵头，但是具体的输入由各项目的负责领导决定。为什么需要这样处理呢？因为一名测试人员在一年当中有可能会做多个项目，如果绩效评定由最后那个项目的负责领导决定，那么他在前面几个项目的表现就会被忽视，所以建议由卓越测试中心牵头，按照每个项目的工作时长，以及项目的重要性设置简单的权重比例，然后综合各项目的反馈对测试人员进行全面的绩效考评。
二是成立测试实践社区（Testing Communities of Practice，TCoP）。在规模化敏捷SAFe中，测试实践社区是被如此定义的：测试实践社区是一个由团队成员和其他专家组成的非正式团体，他们在一个项目群或企业环境中活动，并且拥有在一个或多个相关领域分享实践知识的使命。由定义可知，TCoP不是一个正式的团体组织，所以与卓越测试中心相比，测试人员在其中不会产生那么强的归属感，但是其可以成为测试人员的“精神乐园”，测试人员可以在里面互相学习与分享，减少迷茫感。
文化的转变具体体现为人的意识和思想观念方面的转变。美国著名敏捷测试专家Lisa Crispin和Janet Gregory在合著的 Agile Testing：A Practical Guide for Testers and Agile Teams 中列出了对于敏捷测试人员来说非常重要的10条法则。
·提供持续反馈：测试人员天生就是信息反馈者。
·为客户创造价值：测试人员比开发人员更了解客户需要什么。
·进行面对面沟通：业务团队和开发人员经常使用不同的语言，测试人员可以帮助他们拥有一种共通语言。
·勇气：要有勇气允许自己失败、他人失败，要有勇气寻求帮助。
·简单化：通过最简单的方法验证功能已经达到客户的质量要求。
·持续改进：努力把工作做得更好。
·响应变化：响应变化是敏捷实践的重要价值。
·自我组织：团队文化贯彻于敏捷测试理念。
·关注人：敏捷团队成员互相尊重并认可个人成就。
·享受乐趣：保持对工作的激情。
关于每条法则的详细内容，本书中不再一一介绍，读者可以自行查阅上述经典著作。这10条法则对于已经身处敏捷项目的测试人员来说可以称得上是黄金法则，但是对于正在转型中的传统测试人员，有什么类似的法则可以为他们提供帮助呢？我总结了包括勇气、自我提升、主动沟通、发挥长处和融入团队在内的5条传统测试人员转变法则，为那些想转型或正在转型的测试人员提供帮助。
这里提到的勇气和 Agile Testing：A Practical Guide for Testers and Agile Teams 一书中所说的勇气有相似之处，但也存在一些差异。这里提到的勇气更强调在转型过程中所需要的信心和决心，因为任何转型都会带来一定的不确定性。人们需要离开自己的舒适区，进入自己不能把握和未知结果的区域，因此会产生恐惧。此时如果没有坚持到底的恒心、没有对未来获得成功的信心，那么很可能遇到困难就会放弃，从而使转型半途而废。所以，在转型过程中，最重要的一点就是要有勇气，有勇气坚持转型，最终才可能收获成功。
在转型过程中，如果自身没有过硬的本领，只靠勇气也是行不通的。在传统职能型组织部门，很多测试人员只需专门负责某项工作，这导致测试人员的技能十分单一。而在敏捷型项目中，每个人都需要成为“T”型人才，也就是除了拥有一技之长，还需要有一定的知识面。所以，测试人员需要尽快地学习和补充其他领域的知识，特别是敏捷方面的知识，只有不断提升自我，才能在敏捷项目中做到游刃有余。
虽然在前面我们已经强调了测试人员需要尽快提升个人技能，但是从实际的情况来看，罗马不是一天建成的，知识与技能也不可能在短时间内马上学会并运用自如，需要时间和经验的不断累积。但是，很多项目不会留给测试人员足够的自我学习和提升时间，它们需要的是“招之即来，来之即战”的“即插即用式”的测试人员，此时如果测试人员匆忙“上马”，肯定会遇到很多困难和问题。为了应对和减少因此产生的风险，测试人员需要主动沟通，遇到困难需要尽快告知团队。不少测试人员或许对自己非常自信，以为自己能解决困难，或许为了不让领导觉得自己不能胜任工作，碰到问题不尽早提出，往往等到最后一刻解决不了了才说出来这个“惊喜”，此时即使团队其他成员想帮忙，也可能无力回天。所以，测试人员一定要主动沟通，有问题尽早提出，大胆寻求帮助，从而减少在转型过程中带来的各种风险。
测试人员和开发人员的区别其实只是工作内容上的区别，很多人认为他们在能力上也有差别，认为开发人员的综合技能比测试人员强，这其实是一个误解。原因在于很多项目经理认为开发工作比较难，只有高端人才才能胜任，而测试工作简单，只是点点鼠标，是“熟练工种”，因此，他们在招聘的时候，给开发人员的工资会比测试人员的工资高很多。而在人才市场上，“一分钱一分货”，什么样的工资决定招到什么样的人才，你不能期望一个工资比开发人员少很多的测试人员能力还与开发人员处于同一水平，这显然是不合理的。一位优秀的测试人员能给项目带来的价值和贡献绝对不会比一位开发人员少。对于测试人员来说，最重要的是找到自己的核心竞争力，需要经常审视自己在项目上具备哪些优势，以及能给项目带来哪些价值。例如，测试人员比开发人员更懂得模块之间的上下游关系、对整体的系统架构更有全局感、更熟悉端到端的业务流和数据流等。测试人员还需要考虑如何最大限度地发挥自己的长处，为项目带来一些开发人员无法提供的价值，这样才能在项目中奠定自己的地位，而不是经常抱怨测试人员不受重视，却无能为力。
测试人员在加入项目后，需要转变以前在传统职能型组织架构下的惯性思维，不要把自己当作“质量警察”，而是应该作为团队中的一分子，将自己融入团队。在敏捷项目中，开发与测试没有明确的界限划分，开发人员有可能做测试的工作，而测试人员也有可能帮助做开发的工作。所以，作为测试人员，一定要摆正心态，不能因为这不是测试的工作而拒绝，而是应该在项目出现瓶颈时尽全力帮助团队克服瓶颈，为项目创造价值。
在讨论完敏捷测试文化、组织架构后，接下来讨论敏捷测试流程。在介绍敏捷测试流程之前，我们需要了解Scrum的不同层级和需求的不同抽象层级。
Jeff Sutherland和Ken Schwaber共同发布的《Scrum指南》相对较简单，内容只有20页左右，其中主要阐述一次Sprint的具体执行过程，对版本层级与产品层级并未进行详细介绍。Kenneth S.Rubin的《Scrum精髓：敏捷转型指南》对此做了很好地补充。Kenneth在书中介绍了Scrum的多层级规划，从高到低分别是产品组合规划、产品规划、版本规划、Sprint规划和日常规划，如图3-3所示。
图3-3 Scrum的多层级规划
（1）产品组合规划主要用来确定需要完成什么产品、按照什么顺序完成，以及需要持续多长时间，是考虑将不同产品通过最优组合实现组织利益最大化的过程。一个产品组合包含多个产品。
（2）产品规划主要是获得潜在产品的基本特性并为创建该产品制订大致计划。一个产品规划包含多个版本。
（3）版本规划主要是针对产品按版本的增量交付而实现范围、日期和预算之间的平衡。一个版本包含1次或多次Sprint。
（4）Sprint规划是在每次Sprint开始时进行的，是对团队在本次Sprint中需要做哪些特定的产品待办事项（Product Backlog Item，PBI）达成一致意见的过程。
（5）日常规划其实就是团队的每日例会，它形成的是Scrum中最详尽、最具体的计划。
我们再来看需求的抽象层级结构。在敏捷中，根据需求颗粒度的大小及详细程度的不同，可以划分出不同级别的需求。这是为什么呢？前面已经介绍了Scrum的不同层级，如果在做产品规划或版本规划时使用的是Sprint级别的用户故事，那么需求会显得太细致、太多。试想一下，如果在做产品规划时拿着500个Sprint层级的用户故事向高管介绍，这会让他们湮没在大量无关的细节中，从而迷失重点；而如果用户故事只有一种大小，就必须在一开始把所有需求的细节定义到较小颗粒度的级别，这明显不符合敏捷“刚好够用”（Just-in-Time）的原则。所以在做产品规划或版本规划时，我们不需要这么细致的需求，需要的是更少、更粗略、更抽象的条目。
因此，根据需求抽象程度的不同，可以把用户需求分成以下5个层级，其结构如图3-4所示。
图3-4 用户需求抽象层级结构
（1）史诗：属于最高层级的需求，通常颗粒度比较粗。一般一个史诗为一至几个月，可跨一个或多个版本。
（2）特性：属于第二级别的需求，通常以周为单位，但是对于单次Sprint来说还是有些大。
（3）用户故事：最小粒度的用户需求，以天为单位，必须在一次Sprint内完成。
（4）任务：位于用户故事的下个层级，但是任务不是需求，而是为了完成用户故事需要做的工作。通常任务是一个人独立完成的工作，有时也有可能需要两个人结对完成，一般以小时为单位。
（5）主题：是一组相关联的需求的总称，通常这些需求具有共性或属于同一个功能域。
在了解了Scrum层级及需求抽象层级后，再来看看其对测试有什么影响。不同的敏捷工件需要的测试范围和测试策略也不同。
·代码：在Sprint层级中，需要对代码进行质量扫描和单元测试，主要测试独立的代码单元是否正确。这个测试将在单次Sprint内完成，不会跨Sprint进行。
·用户故事：在Sprint层级中，主要的测试对象是用户故事。我们需要根据用户故事的验收标准进行测试，这个测试是在Sprint迭代的过程中执行的，不会跨Sprint执行。
·特性：在版本发布层级中，测试的对象是特性，主要测试一些用户故事之间如何协同工作，以向用户交付更大的价值。在这个测试中，部分可以在Sprint内完成，部分需要跨Sprint完成。
·史诗：在版本发布层级中还会以史诗为对象进行测试，主要是测试跨多个特性的核心业务流程，通常需要进行端到端的集成测试。这个测试通常要跨Sprint才能完成。
此外，对于非功能性的性能测试，无论是用户故事、特性还是史诗，都需要考虑进行性能测试。在敏捷中，性能测试也需要提前并分迭代执行，不能只在最后阶段才考虑。关于性能测试的具体内容可以阅读7.1节。
通过上述介绍，读者可以了解到，对不同层级的敏捷工件使用不同的测试策略将有助于把测试集中在交付的完整功能集上，从单元测试级别粒度一直到端到端核心业务流，敏捷测试中不同级别的测试类型如表3-1所示。
表3-1 敏捷测试中不同级别的测试类型
注：L1级别主要是针对代码单元组件模块级别进行的性能测试，L2级别主要是针对用户故事级别进行的性能测试，L3级别主要是针对整个版本端到端级别进行的性能测试。
从表3-1中可以看出，有些测试类型是在Sprint内进行的，而有些测试类型是需要跨Sprint执行的，因此，可以简单地把敏捷测试分成两大测试类型：一类是Sprint内测试（In-Sprint Testing），另一类是跨Sprint测试（Cross-Sprint Testing），如图3-5所示。
图3-5 两大敏捷测试类型
Sprint内测试，顾名思义，就是在单次Sprint内可以完成的测试，主要包括如下测试活动。
（1）代码质量活动，如代码扫描等。
（2）单元测试。
（3）用户故事验收测试。
（4）部分特性和能力验收测试。
与Sprint内测试对应，跨Sprint测试需要对多次Sprint或多个Scrum团队的产出物进行集成与端到端的测试，主要包括如下测试活动。
（1）特性和能力验收测试。
（2）史诗验收测试。
（3）端到端集成测试。
（4）回归测试。
从图3-5中可知，在最开始的2～3次Sprint内，因为项目刚刚开始，测试人员更多会考虑Sprint内测试，包括单元测试、代码质量活动、用户故事验收测试，以及部分特性和能力的验收测试等。在进行了2～3次Sprint后，因为有些特性或史诗已经被全部完成，所以在每次新的Sprint结束后，就要把代码提交到系统集成测试环境或发布集成环境中进行端到端的集成测试，如在Sprint 3时需要对Sprint 1和Sprint 2进行端到端集成和回归测试，在Sprint 4时需要对Sprint 1～Sprint 3进行端到端集成和回归测试，以此类推，以Sprint（ N -1）集成测试的方式一直到发布为止。另外，多个Scrum团队的潜在可交付产品可能也需要进行集成测试，这些测试统称为跨Sprint测试，包含特性和能力验收测试、史诗验收/端到端集成测试，以及回归测试，等等。
针对上述两种不同的敏捷测试类型，敏捷测试领域已定义了两组和测试相关的角色。需要特别说明的是，这些角色并非一成不变，而是会不断变化，并且更好地支持敏捷交付。具体角色如下。
（1）Sprint内测试工程师。
Sprint内测试工程师是指拥有深厚的业务知识、BA技能、探索式测试等专业知识和自动化工具技能的人员，其主要职责是对Sprint内的用户故事进行手工或自动化的功能验收测试。
（2）测试开发工程师。
测试开发工程师（Software Development Engineer in Test，SDET）是指对技术有深入了解的人员，其主要对自动化工具有比较深入的研究，特别是非UI自动化测试工具和测试早期阶段（单元测试/集成测试）的自动化测试工具。其主要职责是开发自动化测试工具或框架，以支持开发人员或Sprint内测试工程师更好地进行自动化测试。测试开发工程师更多的是在做为测试赋能的工作，有时测试开发工程师也可以被多个Scrum团队共享，跨多个Scrum团队做贡献。
在Scrum框架中只明确定义了产品负责人、Scrum Master和开发团队3个角色，实际上，上述角色也属于开发团队中的成员。
（1）自动化架构师。
自动化架构师指高级自动化人员，他们对自动化策略、工具市场，以及如何跨产品生命周期和应用程序不同层级技术栈的自动化有广泛的见解，其主要职责是建设自动化测试体系，包括制订分层自动化的策略、选择自动化测试工具、设计自动化测试框架等。
（2）测试架构师。
测试架构师是指具有敏捷交付、DevOps、测试方法、自动化、环境和数据方面的深入技能的资深测试人员，其主要职责是从整体考虑项目的测试策略和测试设计，包括测试方法制订、测试环境管理、测试数据管理、自动化与CI/CD集成等。通常，测试架构师关注的是更具有战略性的重点，而不是负责日常的测试交付。
（3）回归/发布/集成/UAT测试工程师。
回归/发布/集成/UAT测试工程师是指对组织的核心业务流程、集成/接口点，以及通过应用程序的数据流的相关知识有深刻认识的人员，是业务用户或产品负责人的测试代表，其主要职责是进行端到端的业务流回归测试或用户验收测试。他们与Sprint内测试工程师有两个区别：一是主要聚焦于端到端的业务，进行联调/集成/回归/验收等测试；二是代表真正的用户，是更接近用户、更了解用户行为的人。
（4）测试经理。
此处的测试经理不是传统意义上的具有管理权限的角色。众所周知，联调时有许多需要协调的工作，而测试经理的主要职责是负责跨Sprint集成和回归测试的日常交付工作。测试经理可以对Sprint内的测试工作提出建议，但是不会干涉Sprint内测试。
跨Sprint的测试角色不在Scrum团队中，而是独立于Scrum团队之外。在SAFe框架的跨层级面板中，有一个元素叫作系统团队。系统团队是一种特殊的敏捷团队，负责协助构建和使用敏捷开发环境基础设施，包括持续集成和测试自动化，以及自动化交付流水线和执行端到端的集成测试等。跨Sprint的测试角色都属于系统团队。
值得强调的是，这些角色不是一成不变的，他们会根据项目的实际情况进行变化，同时也可以被裁剪，以适应项目的需要。例如，可以把测试架构师和测试经理合并为一个角色，或者把自动化架构师和测试架构师合并为一个角色等。
如图3-6所示为两种敏捷交付类型的敏捷测试组织架构样例，在这种模式下，测试资源可以被充分使用，同时可以为组织各业务线提供专业的测试服务。
图3-6 两种敏捷交付类型的敏捷测试组织架构样例
接下来介绍各敏捷测试角色所需的技能。上述不同的敏捷测试角色会面临不同的测试技能要求，如图3-7所示为敏捷测试角色所需的技能图谱，包括知识域、角色聚焦和工具参考3个方面：知识域列出了敏捷测试人员可能会涉及的技术知识；角色聚焦说明了该测试角色需要掌握的技能，其中，实线区域为该角色必须掌握的技能，虚线区域为该角色最好具备的技能；工具参考列出了不同知识域目前可能会使用的常用商业或开源工具。
图3-7 敏捷测试角色所需的技能图谱
（1）自动化架构师。
自动化架构师必须完全掌握包括技术架构和DevOps、环境/数据/监控、非UI和服务虚拟化、UI自动化测试、测试执行、测试设计和测试管理等知识技能。开发领域的自动化架构师一般不会自己写代码，但是会安排和指导测试开发工程师按照自动化架构设计进行编程。
（2）测试开发工程师。
测试开发工程师必须完全掌握包括开发、技术架构和DevOps、环境/数据/监控、非UI和服务虚拟化、UI自动化测试、测试执行等知识技能。对于测试设计和测试管理，在一般情况下，测试开发工程师对于业务的熟悉程度没有功能测试人员（Sprint内测试工程师、回归/发布/集成/UAT测试工程师）那么高，所以更多的是依赖功能测试人员进行测试用例设计和管理。测试开发工程师需要把功能测试人员编写的手工测试用例转换为自动化测试用例（脚本）。
（3）Sprint内测试工程师。
Sprint内测试工程师必须完全掌握包括UI自动化测试、测试执行、测试设计和测试管理等知识技能。对于非UI和服务虚拟化方面的知识技能，虽然不对Sprint内测试工程师做硬性要求，但是如果Sprint内测试工程师具备类似API测试的技能，就可以为实施测试带来较大帮助。特别是在开发前期，很多时候没有完整的测试环境，如果测试人员懂得服务虚拟化，就可以尽早开展持续集成测试，从而尽早发现缺陷，并以最小的代价进行修复。
（4）回归/发布/集成/UAT测试工程师。
回归/发布/集成/UAT测试工程师必须完全掌握包括非UI和服务虚拟化、UI自动化测试、测试执行、测试设计和测试管理等知识技能。对于需要进行端到端测试的工程师来说，稳定而联通的测试环境、清晰而贯通的数据流等至关重要。虽然可能会有专门的运维人员进行环境或数据管理，但是回归/发布/集成/UAT测试工程师如果掌握环境/数据/监控方面的知识技能，将给测试带来很大帮助。
（5）测试架构师和测试经理。
测试架构师和测试经理必须完全掌握包括环境/数据/监控、非UI和服务虚拟化、UI自动化测试、测试执行、测试设计和测试管理等知识技能。技术架构和DevOps，特别是DevOps部分，是近年来非常流行且重要的内容，自动化测试只有融入DevOps的交付流水线，才能最大化地发挥价值。所以，测试架构师最好能具备这方面的知识，才能设计出与DevOps更加匹配且更加兼容的整体测试方案。
在明确了敏捷测试角色后，再来看敏捷测试转型模型中的流程。敏捷测试的流程根据敏捷测试类型可分为两类：一类是Sprint内敏捷测试流程，另一类是跨Sprint敏捷测试流程。敏捷测试流程如图3-8所示，其中，灰色区域部分表示Sprint内测试流程，而白色区域部分则表示跨Sprint测试流程。Sprint内测试流程主要是针对每个用户故事的验证测试，而跨Sprint测试主要是针对集成和回归的版本测试。需要强调的是，本节提供的敏捷测试流程只是作为参考的模板，并非一成不变，读者可以根据自己的组织和项目特点对流程进行剪裁，定制适合自己项目环境的流程。
图3-8 敏捷测试流程
敏捷测试流程步骤如表3-2所示。
表3-2 敏捷测试流程步骤
续表
注：团队即敏捷实施团队，包括开发人员、Sprint内测试人员和跨Sprint测试人员等。
跨Sprint敏捷测试流程一般应用在版本发布级别，主要适用于多Scrum团队和多Sprint环境下统一协作的情况。跨Sprint敏捷测试流程需要对不同Scrum团队和不同Sprint的交付物进行集成和回归验证测试，最终达到预发布的状态。
但在集成的过程中，主要还是依靠CI/CD流程，同时辅以人工探索式测试来实现。通过CI/CD把多个Scrum团队的应用部署到系统集成环境中，同时运行回归测试，如果验证了这些应用集成不存在问题且顺利通过了人工的探索式测试，就达到了预发布的状态。
根据敏捷测试类型的不同，可将测试交付物分为Sprint内测试交付物和跨Sprint测试交付物。值得注意的是，如表3-3所示的Sprint内测试交付物列表，仅供读者参考，读者可以根据项目的实际情况自行删减。
表3-3 Sprint内测试交付物列表
如表3-4所示为跨Sprint测试交付物列表，同样仅供参考，读者可以根据实际情况自行删减。
表3-4 跨Sprint测试交付物列表
本章讨论了传统测试向敏捷转型需要考虑的领域，总结并提出了敏捷测试转型模型，其中，需要从文化、组织、流程和实践等方面进行剖析和探讨。另外，还提供了敏捷测试的流程及流程所对应输出的测试交付物供读者参考。
本章的主要内容如下。
（1）传统测试向敏捷转型的敏捷测试转型模型介绍，包括文化、组织、流程和实践领域的转变。
（2）从组织文化转变和管理文化转变两方面阐述并讨论了敏捷文化的改变，同时指出了敏捷文化转变可能会遇到的障碍。
（3）探讨了组织架构转变，以及转变后通过建立卓越测试中心或测试实践社区解决测试人员的归属感问题。
（4）针对测试人员在转变过程中遇到的挑战，提出了勇气、自我提升、主动沟通、发挥长处和融入团队5个转变法则。
（5）介绍了Scrum的不同层级与需求的不同抽象层级。
（6）介绍了敏捷的Sprint内测试及跨Sprint测试2种测试类型，同时定义了敏捷测试的角色、职责和所需技能。
（7）根据不同的敏捷测试类型，提供了不同的敏捷测试流程及敏捷测试交付物。