关于敏捷开发的一个常见的误解是，它需要较少的计划或没有计划；这种误解主要与敏捷宣言中的一个核心项目有关，即我们需要 "对变化做出反应而不是遵循计划"。 虽然这在理论上听起来不错，但在复杂的软件开发项目中是站不住脚的（我们可以把它作为一种思维方式，尝试减少计划，但不能忽视它）。
敏捷团队倾向于在项目的不同阶段一直进行计划；是的，这与其他软件开发方法不同，在其他方法中，计划主要是在项目开始时进行，而在敏捷开发中，计划是分小块进行的，重点是完成一个功能、故事或任务所需的内容。
此外，整个规划过程中，我们有一个明确的目标，即不仅仅是实现规划计划；我们利用规划会议来产生快速反馈，以学习和调整，使未来的规划会议更有效、更省时。这些敏捷规划工作和策略与所有敏捷活动相关，因此也用于测试规划；我们以小块和短的反馈循环来规划我们的测试。当团队计划测试时，重点是他们现在需要知道的东西。
对于测试计划，值得一提的是项目的规模和复杂性。在小型的、有经验的团队中，测试的规划可以很简单。他们有工具和知识来考虑测试的类型，他们的自动化要求，以及团队将花费多少精力来完成测试。另一方面，在大型组织中，测试计划可能会变得复杂，因为每个项目都涉及多个团队在同一产品上工作。然而，无论项目的复杂性和规模如何，基本原则都是适用的。
在敏捷项目中，我们在冲刺开始时并不了解每个Epic和Feature的所有细节。有些可能是可预测的和直接的，因为我们以前做过类似的工作，使我们能够理解复杂性、努力和需要的测试。其他的可能更复杂，或者它们对团队来说是如此的新和未知，以至于要拿出信息来处理测试的挑战。在敏捷开发中，我们应该使用一种不同的思维方式，即假设我们会在前期拥有所有的需求，而规划是基于这些信息的。
使用不同的敏捷框架，我们可以通过使用迭代开发和简化的原则来做到这一点；我们看一下规划的层次，并询问团队在每个层次需要知道什么信息。不同的组织会有不同的背景，所以你需要区分哪些是对你的团队和组织至关重要的，哪些不是。
我们在Scrum框架中使用的冲刺的范围内讨论这种方法，但我们也可以将这些概念应用于基于流程的方法，如Kanban。使用基于流程的方法的团队有可能在每个故事完成后发布一个工作增量，或者他们可以积累故事，直到一个功能完成，然后发布到生产中。
在Scrum框架中，很可能是业界最常用的敏捷框架，组织及其团队将有四个主要的细节层次，他们在计划时必须考虑这些细节，同时也要记住整个产品。我使用以下术语来表示这些不同层次的测试规划的精确度。
史诗级。一个或多个团队在一个项目上工作，以特定的时间间隔或在规定的日期发布。一个Epic是许多功能的集合。
特征。一个特征是一个用户故事的集合，代表了对业务有用的功能的业务能力；一个特征的完成时间可能需要多个迭代来完成。一个功能的交付可能涉及许多团队在不同部分的工作。
用户故事。由团队（非功能需求）或产品所有者（业务需求）创建的一小块可测试的功能。无论故事的类型如何，它都应该在一个冲刺阶段完成（在我的团队中，我设定的限制是2-3天）。一个故事是一个由许多任务组成的小组。
任务。属于故事的一部分的工作，只由开发团队定义，完成时间不超过一天。
让我们来探讨如何使你的测试计划适应每个级别，以及讨论文件的级别，风险的级别，以及我上面分享的四个级别中每个级别可能需要的工件。为了表示赞同，让我们假设我们有一个为期三个月的产品发布（每年一个季度），使用跨组织的两周的迭代。在这段时间里，各团队要交付多个功能，每个团队都要在发布周期内负责交付。
在史诗级别，团队应该已经对产品愿景及其目标有了很好的了解，以回答 "我们是否在建造正确的东西 "的问题。高层的测试方法应该涵盖产品的主要测试方面，因为这时你正在计划发布范围内的内容。由于这个层次的规划的重要性，我总是确保我的团队将有一个简单的问题清单，他们可以按照这个清单来确保他们运行一个充分的测试规划会议，例如。
- 你将需要哪些测试环境？
- 是否有任何新的技术需要团队在项目开始前学习？
- 是否有任何新的工具是我们应该购买的？
- 你将使用什么类型的测试类型。
- 计划的覆盖范围是什么（自动与手动）？
- 在发布管道的不同阶段，将测试什么？
这些活动可能涉及到你的交付团队之外的更多部门和团体的帮助，如市场、支持、运营等。例如，你可能需要系统团队运行团队在开发过程中不会涉及的耐力和安全测试，或者向财务团队要求预算来购买团队在测试过程中会用到的新硬件/软件。
史诗
单一团队的产品交付周期
当你的团队在做一个功能/故事时，他们负责完成所有的测试活动（设计、文档、执行和分析）。该团队可能仍然需要外部帮助，如安全专家，但该团队是负责的。当你有一个负责任的团队时，其含义是项目通常很小，只限于几个迭代。
一个由多个团队组成的产品交付周期
让多个团队在同一个项目上工作可以（通常也会）增加复杂性。因此，整体的测试方法应该考虑不同团队开发的代码部分之间的依赖关系，只测试他们的组件或与项目相关的功能。正如你可能猜到的，一旦团队将开始开发和测试与该项目相关的功能和故事，这一层面的测试规划对于取得良好的结果至关重要。
在我的项目中，有一种做法是创建项目 "地图"，以帮助项目中的所有利益相关者；这些地图通常是用 "思维导图 "工具创建的，它有助于将测试工作中涉及的不同方面可视化。此外，在创建这些 "高层 "地图时，我让重要的利益相关者参与进来，他们了解大局，以及这个版本如何整合到系统中。
下面是一些例子，你可以在Epic级别使用的列表。
- 每个测试领域的所有者和责任的地图。
- 产品团队之外或功能之间的所有依赖关系的地图。
- 与每个测试工作相关的所有风险的地图和缓解计划。
- 测试环境和工具的地图，该团队将在项目中使用。
创建这些地图将包含所有团队的信息，以便在他们的功能上工作。它不断地让他们着眼于大局，旨在早期发现可能的集成问题，在测试工作开始之前。这将增加沟通，减少风险。
考虑投资回报，你可以通过帮助你的团队开始工作的功能，同时知道他们可能有什么挑战，并考虑它是他们测试计划工作的一部分，从而节省所有的时间。例如，与其他团队有许多依赖关系的团队会知道，他们需要共同完成他们的代码，并测试不同组件之间的集成。
如果有可能，并且你有足够的信息与合适的人群，你可以考虑在交付周期开始之前创建一个产品发布测试计划；我建议尽量保持它的精简和直截了当。只关注测试计划的高层方面（团队将做详细的测试计划）。在创建他们的测试策略和详细的测试计划之前，要考虑谁是受众，以及什么是必须知道的。另外，在史诗级别上，测试计划应该包括我在上面已经描述过的具体主题，例如。确定测试策略和识别测试风险。
在推进到功能层面之前，最后值得一提的是，团队可能没有足够的信息来创建一个坚实的测试计划。因此，他们可能会决定推迟测试计划，直到任何必要的调查（主要是通过使用秒杀解决方案）和更多关于复杂的功能之后。
特征层面
特征是由其Epic驱动的工作单元，代表一些业务价值的能力，被分解成用户故事。我们需要确保这些故事（功能故事，有时也包括非功能故事）是可测试的，这样参与项目的团队就会进入编码和测试每个故事的节奏，直到完整的功能 "完成"。记住，一个功能是一组故事，有时可能有许多故事。每个交付团队都专注于一个特定的功能，但并不总是知道其他团队在做什么；当涉及到多个团队时，这种不确定性会增加（我曾经在一个有50多个团队并行工作的项目上工作过）。各个团队之间可能存在着依赖关系。
以Scrum为例，每个Scrum团队与产品所有者（PO）合作，根据他们的能力、容量等确定团队在交付周期内可以完成多少工作。在Scrum中，团队将举行计划会议，以便团队能够了解他们需要实现的目标，并与PO合作，了解他们需要根据其优先级（由PO设定）交付哪些故事。那么测试活动呢？这就是测试人员的价值所在，他们会问一些澄清性的问题，帮助团队确定功能或故事的大小，以了解交付该功能所涉及的实际工作。
测试人员还可以帮助团队考虑对其他系统组件和问题的影响，同时将代码与系统的其他部分整合。另外，他们还可以促进测试思维，了解可能存在的安全或性能问题。正如我在Epic级别提到的，功能级别的测试涉及不同的假设和风险，这些假设和风险需要被监控并记录在专门的资源库中（Wiki、思维导图、Confluence、SPO等），对与项目相关的工程和业务利益相关者可见。观察团队如何使用这些信息，并确保你使用回顾会议和其他专门的会议不断改进这些信息，以确保你使用正确的格式。如果存在沟通上的差距，寻找最适合自己情况的方式。
有时，经理或客户会要求一个正式的测试文件，概述你的团队在交付周期中要测试什么。在你创建一个正式的文件之前，我建议你用一种能让其他非技术性利益相关者理解的方式来写，并尽量保持简单（一到两页，不涉及范围的细节，除非明确要求）。你必须考虑到谁会使用它，以及他们为什么要使用它。在我的项目中，如果这个文件没有被要求，我仍然试图确保任何测试风险将被写入并与任何感兴趣的人分享（我的首选是创建一个思维导图，捕捉这些风险和任何其他我认为必要的信息）。
当是时候将功能分解成故事时，我与我的团队的产品负责人一起工作，创建高层次的验收测试，使用预期行为和功能的非正常行为的具体例子。按照这种方法，你可以帮助你的团队专注于适当的工作范围，并保持尽可能高的商业价值。尽量使用思维导图（这将是值得的，我可以向你保证），与你的整个团队一起为该功能创建一个测试策略，然后再将其分成较小的部分，作为迭代故事的一部分来执行。这是开始讨论的一种方式，允许所有团队成员做出贡献，并在他们出现之前揭示隐藏的差距或潜在的问题。
正如你可能知道的那样，为包含多个用户故事的广泛功能规划测试活动是很复杂的。为了帮助团队，我指示他们为这些添加一个专门的 "功能测试 "故事。该故事将包含与测试活动相关的任务，如 "创建自动化策略"、"设置测试环境"、"探索功能"、"定义测试工作 "等等。这种类型的故事可以确保在特定的迭代中，功能测试是作为一个团队的努力来完成和计算的。
故事层面
一旦我们在功能层面设定了测试计划，团队将开始在故事层面工作，从 "宏观 "到 "微观"。在这个精确的层面，我们需要（每个故事）设定高层次的验收测试：一个预期需求的例子和至少一个错误行为的例子，定义故事的范围和团队必须运行的必要测试来验证它。故事级别的规划发生在故事准备会议期间（有时称为克制或积压梳理），这有助于团队为故事创建测试，可以在迭代规划会议期间消耗。
因此，如果想简化我建议的过程，我们将使用reediness会议，根据你已经拥有的信息和知识，在功能层开始编写测试想法，在迭代计划期间继续，然后扩展到其他测试，以保证所需功能按预期运行。
任务层面
当考虑到任务层面的测试活动时，计划和执行相关的活动较少，如创建测试数据、设置环境、编写单元测试等。有些团队在迭代计划中估计任务，但我认为这是浪费时间，因为估计应该只在故事层面上进行。然而，这对刚接触敏捷的团队来说是有用的。当迭代开始并执行测试时，一定要在日常的站立中引起注意，报告进展情况或在测试任务比预期的时间长时请求帮助。
