许多软件开发人员和质量保证团队对向敏捷的飞跃感兴趣，但可能对促进这种转变所必需的改变犹豫不决。在敏捷环境中工作与传统的瀑布方法有很大不同，需要一种新的 QA 管理方法。如果团队领导未能做出必要的调整，他们的敏捷计划即使没有彻底失败，也可能会动摇。这里至关重要的是改变团队为任何项目制定 敏捷测试计划 的方式。
退一步制定计划
QA 资深人士 Yvette Francino 在 TechTarget 撰文评论说，组织应该抵制在新项目开始时投入自动化测试的冲动。这似乎与一些更广为人知的敏捷原则形成鲜明对比，包括尽可能使用自动化测试脚本以及尽早将 QA 引入生产过程。然而，Francino 告诫说，即使敏捷专注于速度和灵活性，任何项目要想取得成功，仍然需要制定一些类似的计划或战略。
在为敏捷环境制定测试计划时，重要的是要始终专注于特定开发项目的总体目标，不要太拘泥于细节。第一步是确定在生产过程中需要进行哪些类型的测试。 Francino 建议对此任务使用敏捷测试象限方法，这有助于按需求、目标和测试类型分解任务。
这样，团队可以提前计划需要多少自动化和 手动测试 ，以及将这些工作集中在哪里。
QA 团队还可以使用敏捷测试自动化金字塔为其自动化测试生成优先级列表。这通过创建自动化资源来促进敏捷流程，以便在生产生命周期的早期评估基本功能，然后再转向其他软件功能。“自动化是任何敏捷软件测试策略的重要组成部分，”Francino 写道。 “但是，有不同类型的测试和不同类型的自动化。使用敏捷测试自动化金字塔和测试象限，您将创建一个可靠的策略来全面测试您的应用程序。”
永远不要孤立地计划
就像在瀑布环境中一样，敏捷团队应该接受测试计划，以便参与项目的每个人都准确地知道他们的角色和职责是什么。如果团队领导发现很难将测试计划纳入他们繁忙的敏捷计划，QA 专家 Karen Greaves 建议将其纳入他们的冲刺计划流程。 Greaves 在她的博客上写道，冲刺计划和总体测试计划的目标非常吻合，因此在那个阶段涵盖两者是有意义的。
要避免的一个常见陷阱是将测试计划职责分配给一个人甚至少数团队成员。这不仅会违背敏捷的协作精神，而且还会阻止其他项目利益相关者有机会提供他们的意见并找到解决战略问题的替代解决方案。此外，社区规划可确保每个人都在同一页面上，并对如何为特定项目定义质量有一个坚定的理解。 QA 团队可以通过实施 测试管理软件 来共享关键文档和资源（例如敏捷测试计划）来进一步支持内部协作。这样，团队负责人可以确保所有测试人员都可以访问概述的策略，而不仅仅是坐在某个地方的白板上。