在过去几年中，一种创建软件的新方式已经风靡软件开发和测试世界：敏捷。

事实上，根据VersionOne的敏捷状态报告，截至2018年，97％的组织以某种形式实践敏捷。然而，受访者表示，这种采用在其组织中并不总是很普遍，这意味着在采用和成熟方面还有很长的路要走。

那么究竟什么是敏捷的，为什么它如此迅速地变得如此受欢迎？让我们更详细地探索敏捷方法所涉及的内容以及如何在组织中引入它。具体来说，我们将涵盖：

测试如何适应敏捷方法？

在敏捷团队上测试的不同方法有哪些？

敏捷运动的下一步是什么？

关于敏捷方法论

敏捷方法已经风靡软件开发世界并迅速巩固其作为“黄金标准”的地位。敏捷方法论都是基于敏捷宣言中概述的四个核心原则开始的。这些方法植根于适应性规划，早期交付和持续改进，所有这些都着眼于能够快速，轻松地响应变化。因此，在VersionOne的2017年敏捷状态报告中，88％的受访者认为“适应变化的能力”是拥抱敏捷的头号优势，这一点也就不足为奇了。

然而，随着越来越多的开发团队采用敏捷理念，测试人员一直在努力跟上步伐。这是因为敏捷的广泛采用促使团队更频繁地发布版本和完全无证的软件。这种频率迫使测试人员在进行测试时，他们如何与开发人员和BA一起工作，甚至他们进行的测试，同时保持质量标准。

对敏捷团队进行测试意味着什么？

敏捷原则都是关于协作，灵活和适应性的。它建立在现在世界变化的前提下，这意味着软件团队不再需要多年才能将新产品推向市场。在那段时间内，竞争对手的产品或客户期望可能会发生变化，而团队的风险则无关紧要。敏捷通过适应团队成功所需的内容，帮助团队更多地协作，从而最大限度地降低风险。它通过鼓励团队定期展示他们的工作并收集反馈以便他们能够快速适应变化来实现这一目标。

快速启动您的敏捷协作：阅读我们的文章“开发人员和测试人员之间保持一致的秘密”。

缩小测试范围，敏捷开发的快节奏为测试人员带来了几个必要条件：

根据风险确定需求的优先级，因为无法测试所有内容

自动化测试以提高效率

增加探索性测试的使用，以加快从代码交付到测试完成的时间，并强调创建有效代码的必要性

适应从冲刺到冲刺的变化

第四个必要条件 - 适应性 - 特别重要，因为它要求测试人员具有更广泛的跨功能测试技能，这代表了与瀑布环境中经常需要的较窄测试技能的背离。此外，与瀑布环境不同，遵循敏捷方法的测试人员需要与开发人员保持密切联系，以便在整个软件开发生命周期中协作进行测试。在瀑布式方法中，通常会有一个大型的需求文档供测试人员测试。该文档不会经常更改，因此测试人员可以相当独立于开发人员而存在。但是，大多数敏捷方法对文档都很清楚，新功能的要求可能只在需求跟踪系统中的票证中，而没有列出所有边缘情况。这些场景中的测试人员需要与开发和业务团队进行高度沟通，因为几周前他们编写的测试可能很快就会过时。为了取得成功，测试人员需要灵活并能够适应移动目标。

为了取得成功，测试人员需要灵活并能够适应移动目标。

一般而言，敏捷宣言有四个核心原则，对于测试人员来说很重要：

个人和流程与工具之间的互动

通过综合文档工作软件

响应遵循计划的变更

通过合同谈判与客户合作

所有这一切的底线是，每个人 - 测试人员，开发人员和其他人 - 必须发展才能拥抱敏捷的工作方式。

敏捷不是放之四海而皆准的

每个组织都是独一无二的，面临着不同的内部因素（即组织规模和利益相关者）和外部因素（即客户和法规）。为了帮助满足不同组织的不同需求，您可以在其中一种敏捷方法中使用各种敏捷方法和几种不同类型的测试。哪种组合适合您的团队取决于您的内部和外部因素，需求和目标。让我们来看看一些最流行的敏捷方法和测试方法，包括：

敏捷方法论

Scrum

看板

测试方法

行为驱动开发（BDD）

验收测试驱动开发（ATDD）

探索性测试

基于会话的测试

敏捷方法论类型

1）Scrum

它是什么？作为最受欢迎的软件测试方法之一（58％的组织已根据VersionOne采用了敏捷方法），Scrum采用高度迭代的方法，专注于在每个sprint之前定义关键特性和目标。它旨在降低风险，同时快速提供价值。

Scrum从一个需求或用户故事开始，概述了功能应该如何执行和测试。然后，该团队通过一系列冲刺循环，以快速提供小规模的价值爆发。为了帮助团队以这种灵活的方式工作并避免改变优先级，Scrum要求从一开始就回答问题。

它和瀑布有什么不同？瀑布包括在发布产品之前的几个测试和错误修复周期，而Scrum更具协作性和迭代性。其中一个最大的区别是瀑布早期需要大量文档。这个文档使得在过程继续进行时更改功能变得更加困难，这在某些环境（例如消费级软件）中可能是负面的，而在其他环境中则是积极的（例如团队试图发射火箭的那些）没有人想要经常危险移动的要求）。也就是说，您可能会认为Scrum就像许多“迷你瀑布”一样，因为每个冲刺开始时需求都很明确，不应该在其中移动。不同之处在于，下一个冲刺的详细要求不是提前几个月设定的。

潜水更深入，Scrum要求测试人员，开发人员和BA之间进行更多定期协作，通常采用每日站立和冲刺回顾的形式，以确保正确的沟通和协调。此外，还有一位Scrum Master通过删除团队中的阻截者来确保他们最有效，从而帮助项目完成任务。Scrum Master可以是团队中的任何人，例如开发人员或测试人员。

采用有什么意义？Scrum为来自瀑布环境的团队提供了最简单的转换之一，因为它基于时间的冲刺和发布仍然可以提前计划。也就是说，它确实需要更快的迭代和更强的协作。

它是谁的？由于其快速迭代，Scrum最适合那些客户和利益相关者希望通过在展示会议上定期查看工作产品而积极参与的团队。此协作允许团队对即将到来的陈列柜进行更改。在采用Scrum方法时应该参与的主要团队成员包括：

产品拥有者

Scrum Master

开发商

自动化工程师

测试者

利益相关者

什么是最佳做法？除了强大的沟通，协作和适应性之外，遵循Scrum方法的测试人员的其他最佳实践还包括：

根据销售代表或客户的通信（通常以用户故事的形式）确定验收标准（注意：此直接连接应有助于减少误传）

使用验收标准开发代码并确保团队批准该代码

在将其部署到生产环境之前，在类似沙箱的环境以及类似生产的环境中测试代码

2）看板

它是什么？看板是一种非常简单的基于敏捷的方法，植根于制造业（它由丰田公司开发，旨在帮助提高工厂的生产率）。在它的核心，看板可以被认为是一个大的，优先的待办事项列表。与Scrum一样，看板中的需求由其当前阶段（待办，开发，测试，完成）跟踪。

与Scrum不同，看板不是基于时间的。相反，它完全基于优先权。当开发人员准备好完成下一个任务时，他/她将其从待办事项列表中拉出来。由于计划会议较少，这种方法意味着团队需要非常接近。在这种类型的环境中，如果开发人员的工作速度比测试人员快得多，那么就会出现瓶颈。在这些情况下，团队中的任何人都应该跳进并帮助不同的领域。当然，满足这种需求需要很大的灵活性和适应性。

它和瀑布有什么不同？看板仍然有像瀑布这样的要求，但是由于测试团队没有开始考虑测试每个要求，直到开发人员从积压的顶部选择它，因此需求可能会发生变化。相比之下，瀑布是基于时间的，在计划中有很多开销。在某些情况下，在瀑布环境中进行繁重的规划是很好的，例如在建造昂贵的东西时，但并不总是必要的。使用看板，版本仍然有计划，但团队通常不会在某些日期向任何人提供功能，除非相关项目位于待办事项的顶部。

采用有什么意义？看板为正确的团队提供简单的过渡。为了顺利过渡到看板，业务分析师，开发人员，测试人员和利益相关者应该坐在一起并定期沟通。转换到看板时，重要的是要记住这种方法提供了将代码投入生产的最快方法，但代码可能会有一些技术债务。这是因为开发时并不总是知道接下来的内容并不一定能够生成最可重用的代码。

它是谁的？看板最适合不为公众制作功能和/或承诺发布某些日期的小型团队或团队。此外，它是主要专注于维护工作的任何产品或团队的首选方法选择，因为错误并不总是直截了当，往往需要研究解决，这使得时间管理具有挑战性。根据Scrum或Waterfall方法，不能最小化问题规划量的团队可能会更好。

应参与看板环境的主要团队成员包括：

产品拥有者

专案经理

开发商

自动化工程师

测试者

什么是最佳做法？除了保持可见性和优先协作之外，遵循看板方法的测试人员的最佳实践还包括：

在业务所有者，开发人员和测试人员之间保持非常开放的沟通渠道

确保团队可以灵活地承担其核心职责之外的其他角色，以帮助消除瓶颈

让每个人都成为产品的所有者，以便他们完全关注结果

敏捷测试方法

1）行为驱动开发（BDD）

它是什么？很多人都听说过或使用过测试驱动开发（TDD）。例如，开发人员在编写代码之前使用TDD编写单元测试失败。BDD基于与TDD相同的原则，但它不是单元测试，而是要求在业务级别进行更高级别的测试。BDD不是像TDD那样从面向技术的单元测试开始，而是从基于最终用户行为的初始需求开始，并且需要“人类可读”的测试，甚至可以替换一些需求文档。此要求基于产品应展示的行为，为工程师在开发测试时使用创建气密指南。

有关更多信息，请阅读我们的文章：“为什么BDD是DevOps中的测试秘诀。”

具体来说，BDD使用Gherkin Given / When / Then语法从功能规范开始。然后，该规范指导跨功能的开发人员，测试人员和产品所有者。正如他们所做的那样，他们使用自动化测试功能来确定完整性，改进代码直到通过测试，就像TDD方法一样，除了团队级别。为了确保测试通过（并且通常需要多次尝试），开发人员应该只重构代码，而不是添加任何新功能。

总而言之，BDD需要一种“智能”自动化策略，以提高效率。该策略将BDD与其他敏捷方法区分开来。

它与标准瀑布测试有何不同？BDD与标准的瀑布测试极为不同，因为前者要求在需求的早期编写测试用例，并要求在开发周期结束时执行这些测试。但是，在敏捷环境中使用BDD，测试不是基于需求，测试是在功能开发的情况下进行的。

此外，在Waterfall方法中，测试人员是编写测试用例的人。另一方面，BDD方法适用于编写测试的企业主。此开关可减少业务分析人员，开发人员和测试人员之间的通信（或沟通错误）。

采用有什么意义？当团队习惯于传统的测试方式时，更改为BDD方法可能具有挑战性。它需要BA或测试人员预先编写测试，并且开发人员要在代码中编写测试规范以进行匹配。这是团队内部的一种新型协调方式，但非常积极的是团队合作为一个单元，包括业务用户。

它是谁的？BDD方法非常适合从事以功能为中心的软件和/或将用户体验放在首位的团队的团队。应参与BDD环境的主要团队成员包括：

产品负责人/业务分析师

专案经理

开发商

自动化工程师/测试员

什么是最佳做法？遵循BDD方法的测试人员的最佳实践包括：

简化文档以保持整个流程的精益

采用“三友”模式，产品所有者，开发人员和测试人员组成一个有凝聚力的团队

使用像Cucumber这样的测试框架来定义标准

以尽可能容易重用的方式构建自动化测试

让业务分析师学习Gherkin语法并直接编写测试用例

2）验收测试驱动开发（ATDD）

它是什么？ATDD就像BDD一样，它要求首先创建测试，并要求编写代码以通过这些测试。然而，与TDD中的测试通常是面向技术的单元测试不同，在ATDD中，测试通常是面向客户的验收测试。

ATDD背后的想法是用户对产品的感知与功能同样重要，因此这种感知应该推动产品性能，以帮助提高采用率。为了实现这一想法，ATDD收集客户的意见，使用该输入来制定验收标准，将该标准转换为手动或自动验收测试，然后根据这些测试开发代码。与TDD和BDD一样，ATDD是测试优先的方法，而不是需求驱动的过程。

与TDD和BDD方法一样，ATDD通过消除开发人员解释产品使用方式的需要，帮助消除潜在的误解区域。ATDD比TDD和BDD更进一步，因为它直接进入源（也就是客户）以了解产品的使用方式。理想情况下，这种直接连接应有助于最大限度地减少在新版本中重新设计功能的需要。

它与标准瀑布测试有何不同？ATDD与标准瀑布测试不同，因为它是测试优先方法。标准瀑布测试要求根据需求预先编写测试用例，而ATDD不是需求驱动的测试过程。

采用有什么意义？因为ATDD代表了与传统方法的背离，所以从一个到另一个并不容易让团队去做。为了处于采用ATDD方法的最佳位置，团队需要获得利益相关者的支持，这有时会证明是有挑战性的。

它是谁的？由于强调用户感知，ATDD最适合专注于用户体验的团队，具有高采用率的目标，并希望在未来版本中尽量减少功能更改的数量。应参与ATDD环境的主要团队成员包括：

客户/客户代言人

开发人员

产品负责人/业务分析师

自动化工程师/测试员

专案经理

什么是最佳做法？遵循ATDD敏捷方法的测试人员的最佳做法包括：

与客户密切互动，例如通过焦点小组，以确定期望

倾向于面向客户的团队成员，如销售代表，客户服务代理和客户经理，以了解客户的期望

根据客户期望制定验收标准

优先考虑两个问题：

如果是X，客户会使用该系统吗？

我们如何验证系统是否支持X？

3）探索性测试

它是什么？接下来我们进行探索性测试，这实际上是一种功能测试，但在敏捷环境中非常重要。探索性测试使测试人员对代码拥有所有权，以有组织，混乱的方式对其进行测试。在这种情况下，测试人员不会遵循测试步骤，而是以标准或巧妙的方式使用软件来尝试打破它。测试人员将像往常一样记录缺陷，但并不总是提供有关应用程序测试内容和方式的详细文档。

探索性测试不是脚本化的。相反，它是基于每个独特的软件开发最佳测试。由于其无脚本方法，探索性测试通常模仿用户在现实生活中如何与软件交互。

总体而言，探索性测试遵循以下四个关键原则：

并行测试计划，测试设计和测试执行

具体而灵活

协调调查潜在的机会

知识共享

它与标准瀑布测试有何不同？探索性测试实际上可以在Waterfall和Agile环境中完成，但是敏捷环境中测试人员和开发人员之间的紧密集成有助于缓解在瀑布环境中运行探索性测试时可能出现的任何瓶颈。

此外，为了在Waterfall环境中运行探索性测试，必须提供有关测试结果的文档，并且该文档应该易于追溯到需求。当然，这种类型的文档在任何环境中都是有用的。

采用有什么意义？拥抱探索性测试相对容易，因为它可以快速启动（和扩展），简单易学并为整个团队带来好处。也就是说，重要的是要记住，它不应该是唯一的测试形式（相反，它应该告知接下来会发生什么类型的测试）。此外，即使它没有脚本，探索性测试也不应该是非结构化的（测试人员仍然需要设置目标，记录您的活动并采取特定用户角色的思维模式）。

它是谁的？探索性测试有助于减少测试时间，发现更多缺陷并提高代码覆盖率。因此，探索性测试最适合受时间限制的团队，需要帮助确定要运行的最佳测试类型的团队（特别是在没有开发人员规范的情况下）以及希望确保他们没有的团队以前的测试都不会错过任何东西。应参与探索性测试的主要团队成员包括：

测试人员（虽然团队中的每个人都应该以某种方式参与）

什么是最佳做法？使用探索性测试的测试人员的最佳实践包括：

使用Mindmap或电子表格等组织应用程序中的功能

专注于某些领域或某些场景

跟踪经过测试的内容，以帮助重现任何错误

在qTest Explorer之类的工具中记录结果，因此对测试的内容有一定的责任感

4）基于会话的测试

它是什么？最后，让我们回顾一下基于会话的测试。基于会话的测试建立在探索性测试的基础上，提供更多结构因为探索性测试完全没有脚本，所以它使问责制变得困难，并且在很大程度上依赖于所涉及的测试人员的技能和经验。基于会话的测试旨在通过为探索性测试带来更多结构来缓解这些缺点，而不会剥夺探索性测试提供的好处，例如更好地模仿用户体验和通过测试获得创造性的能力。

基于会话的测试通过在时间限制的，不间断的会话期间进行测试，针对章程进行测试并要求测试人员报告每个会话期间发生的测试来提供此结构。此外，基于会话的测试应该通过测试人员和管理人员之间的“汇报”进行限制，其中包括五个PROOF点：发生了什么（过去），取得了什么（结果），阻碍了什么（障碍） ），还有什么需要做的（Outlook）以及测试人员对此的感受（感受）。

它与标准瀑布测试有何不同？与探索性测试相同，基于会话的测试可以在Agile和Waterfall环境中运行，但它更有利于敏捷环境中常见的测试人员和开发人员之间的紧密协作。

采用有什么意义？与探索性测试非常相似，采用基于会话的测试证明相对容易，因为它易于快速启动和启动。对于已经习惯于探索性测试的测试人员来说，最大的障碍是采用基于会话的测试调用的附加结构。与探索性测试一样，运行基于会话的测试的团队应该记住它不是最后一站，而是一种帮助确定下一步要进行的最佳测试类型的方法。

它是谁的？基于会话的测试有助于缩短测试时间，同时增加缺陷发现和代码覆盖率，使其成为面临时间限制并需要更多指导以确定要运行的测试类型的团队的理想选择。对于在探索性测试中获益但需要在整个过程中改进问责制的团队而言，它也是理想的选择。应参与基于会话的测试的主要团队成员包括：

测试者

经理

什么是最佳做法？使用基于会话的测试的测试人员的最佳实践包括：

概述任务，以便测试人员清楚他们正在测试的软件

开发一个明确的章程，指明任务，要测试的软件区域，运行会话的测试人员，会话将在何时进行，以及设计和执行的测试，发现的错误和整体说明（与探索性测试一样，像qTest Explorer这样的文档工具可以在这里提供帮助）

在没有任何中断的情况下运行测试会话

在会议报告中明确记录会议期间的活动和说明

在测试人员和经理之间进行汇报，以审查会议的结果并讨论下一步的测试步骤

如何使测试与敏捷交付流程保持一致

一旦确定哪种测试方法适合您的组织，您就还没有完成。您仍需要将测试与交付一致。为实现这一目标，我们建议采用三管齐下的方法：

1）尽早参与开发过程

测试人员越早参与，越好。理想情况下，测试人员应该从第一天起就在场。这是因为让测试人员在桌面上的每一步都能提供更高水平的需求和目标洞察力，鼓励合作并帮助确定频繁（如果不是连续）测试的必要性。

2）经常测试，但是很周到

随着越来越多的团队采用敏捷方法，效率就是一切。这种对速度的需求促使团队采用DevOps和持续集成以保持移动，这需要更频繁地进行测试。但是在效率和频率集中的重组中，测试人员需要保持周到，以免产生更多开销并运行不必要的测试，这实际上会减慢过程。

3）通过测试创建来运行

牢记在当今敏捷，DevOps驱动的世界中对速度的需求，测试人员需要在创建测试时立即投入运行。具体来说，越多的测试人员可以减少从需求收集到测试创建的时间越多越好。从一开始就在所有谈话中坐下来应该有助于这方面。

敏捷测试的下一步是什么？

虽然敏捷已经在软件开发生命周期中取得了重大进展，但仍有很长的路要走，特别是在测试团队中。

展望未来，更广泛的采用和更加成熟的敏捷方法将要求测试人员超越测试创建和执行，并开始专注于代码交付和集成。与此同时，测试人员需要磨练自己的自动化技能，更多地参与整个软件开发过程，并继续与开发人员建立协作关系。最终，这些变化还将要求测试人员成为开发和产品使用方面的专家，以便提供更全面的测试策略并承担“质量冠军”的角色。

将来，对于在敏捷环境中工作的测试人员来说，三个关键原则将变得尤为重要：

1）沟通

敏捷需要测试人员和开发人员之间的紧密协作，而这种协作使通信成为测试人员的首要任务。此外，在质量成为每个人的责任的世界中，测试人员将成为内部专家的“质量冠军”，这将使他们能够在聚光灯下清晰地传达测试需求和推理。

2）技能多样性

在敏捷环境中，一切都可以改变，这需要测试人员适应。这种适应性的一部分是拥有多样化的技能组合，以便测试人员可以根据需要改变方向。例如，功能测试人员需要将他们的技能扩展到手动脚本执行之外。这种多样化的技能组合是必须的，因为不同的冲刺需要在短时间内执行不同类型的测试。

3）商业心态

最后，Agile采用以客户为中心的方法，以确保客户尽可能快地尽早获得尽可能多的价值。测试人员在提供这一价值方面发挥着重要作用，但它需要他们采取商业思维方式，以便他们能够理解客户的期望，愿望和关注，并相应地制定他们的测试策略。