敏捷项目的特点是需求变化快、项目周期短。传统的极致详尽的测试计划已经不符合敏捷的项目了，因此 需要简化，需求精准，需要自动，需要更加注重团队沟通，需要拥抱变化。
本文介绍了我们对测试计划的一点思考和实践。
1、一定要有测试计划
测试计划是指导测试过程的纲领性文件。是为了达成一定时期内的目标，进行的任务规划和行动步骤设计。
说人话就是：你打算做什么？怎么做？谁来做？用多少时间 ？有什么风险？怎么规避？等等。。。这就是测试计划。
为什么要做测试计划？
当然是不打无准备之仗。
如果你了解 PDCA，这个 P 对于我们测试来讲就是测试计划。
当我们接手一个项目的测试时，要知道项目要做什么？目标是什么？要理清楚需求的优先级、开发是谁、何时提测、依赖什么、影响什么、有无风险，要盘一盘工作量、资源、分工、节奏、标准、策略等。
这些都是做测试计划。
可能你也遇到过这样的问题：
- 开发前期提测的功能较少，临近发布，才批量提测，导致来不及测试...
- 待测功能依赖外部团队的一个新接口，但新接口什么时候给出来没有明确的时间，然后就导致一直等待，阻断进度。
- 当我们正在「开心」的测试，突然来了个需求变更，打断了工作节奏，不知道怎么调整。
- 正在努力测试，突然团队中有一个人请假，然后就乱了节奏。
- ...
这些问题的主要原因就是没有做好计划。有了计划，才能有节奏，才能不乱，即使出现计划外的事情，也能按计划进行合理的调整，逐步找回节奏。
所以一定得做计划。
2、测试计划应该怎么做？
原则：一次制定，持续优化。
测试计划不可能面面俱到，项目也不可能一成不变，需求变更、提测延期、依赖延期、有人请假等等情况都会不可避免的发生，因此，计划要先有一个基线，然后根据这个基线，按突发情况导致的时间/风险进行合理调整。
计划的调整可以遵循以下的 4 个原则：
- 需求宣讲中未能最终确定下来的内容，确定后，需要更新测试计划；
- 对已有计划会产生明显影响的变更，需要更新测试计划；
- 对质量目标有明显影响的变更，需要更新测试计划；
- 小的改动，经评估对原计划无影响时，无需更新测试计划。
内容：需求、资源和质量
测试计划主要关注：需求、资源和质量。即在有限的时间内，用有限的资源，完成所提的产品需求，达到一定的质量目标。
要完成哪些产品需求，要达到什么样的质量目标，怎么去分配这有限的时间和资源，就成了计划的关键。
由此可以拆解出更多需要关注的信息：
注意：评估风险、评审计划
评估风险
提到风险评估，大家会觉得这个词并不陌生，但如果真正要对一个项目做风险评估，很多人会觉得无从下手，因为我们要考虑的是还未发生的事情。
如果不知道从何下手，不妨先试试把各式各样的风险分个类。然后按照时间线，来想一想在项目的不同阶段，我们可能会遇到哪些问题。
如下表所示：
评审计划
测试计划评审，是一个公开的，接受每个角色检验的，能够从不视角查漏补缺的机会，一定要抓住这样的机会。
可现在的项目，往往会议比较多，产品需求要评审、视觉/交互/技术设计要评审、测试计划要评审、测试用例要评审...
那测试计划应该怎么评审？
我们比较认同的评审方式可以分为两种：
- 常规迭代可以不用大范围组织评审的，只要确保信息互通，确保你的测试策略是对应的开发认可的，就足够了。因为人员稳定、测试阶段固定，大部分迭代的测试计划内容都是通用的，只重点分析测试策略和风险即可，只要保障测试人员了解开发的设计和重点难点，能够针对性的产出较为规范的测试策略，就没有什么太大的问题。
- 而对于较为重大的迭代，有多个团队参与，涉及外部交互的，这种迭代是一定要组织测试计划评审的。不仅要把你的测试计划同步给其他团队，也要能了解其他团队的测试安排，这样更有利于大家达成质量上的共识，也更容易在测试时间和测试阶段上保持一致，以防后期大家进度不一致，互相掣肘。
3、测试计划的平台化支持
我们谈敏捷时，一定少不了工具和平台的支持，特别是测试计划，更合适平台化。工具有很多，这里就不细说了。
总结
还是那句话，不打无准备之仗，测试计划就是我们打胜仗的关键，做好测试计划就是减少例外的事情发生，即使发生了也不至于手忙脚乱，再加上平台工具的支持，相信一份「好的」测试计划带来的收益会越来越明显。