它是谁的？ 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采用以客户为中心的方法，以确保客户尽可能快地尽早获得尽可能多的价值。测试人员在提供这一价值方面发挥着重要作用，但它需要他们采取商业思维方式，以便他们能够理解客户的期望，愿望和关注，并相应地制定他们的测试策略。
为什么领先的公司正在通过敏捷测试实现敏捷
超过300家领先的公司选择改进他们的软件测试流程，并通过采用敏捷。以下是其中一些领导者为什么选择使用qTest而说的原因：
“我们能够快速将所有测试案例从惠普质量中心缓解到qTest，并在短短几周内启动并运行团队。实施过程非常好“
-Radka Iordanova，Office Depot，Inc。电子商务总监
“当你转向敏捷时，仅仅改变你的开发方法还不够，你必须升级你的软件工具...... QASymphony正是我们所寻找的。”
-Alex Bantz，Salesforce Marketing Cloud质量工程总监
“我们已经看到了测试者错误的大幅减少，现在我们已经有了缺陷的历史。我们可以看到问题所在。 American Equity和QASymphony之间的合作非常精彩。“
-Dennis Young，美国股票QA助理副总裁
“我们评估了很多其他测试平台，发现qTest是最好的，而且到目前为止最直观......自首次实施qTest以来，我们的效率提高了至少50％。”
-Jesse Reynosa，Zappos高级质量工程师
特别感谢Ali Huffstetler为这个博客绘制图像。
