《漫谈测试成长之探索——测试文档》一文阐述了我们可以从项目维度去整理测试相关的文档来提升自己，本文将从测试排期方面探索成长方向。
我们知道，对于做一件事，我们要有计划，要知道目标，要记得看时间。这里的时间对应到软件测试中就是与测试相关的时间节点。如图 1-1 所示，在以往工作中，作为一线测试执行者，我们一般会关注开发计划提测时间、测试计划开始时间、测试计划完成时间和需求计划发布时间。但是，经验告诉我们，只关注这些时间节点似乎是不够的。在实际工作中，需求实际可测试的时间经常延期，测试时间被压缩的情况时有发生。
图 1-1 传统测试排期时间节点
那我们能做些什么去规避或者说减少测试工期被压缩的情况呢？本文的答案是：“作为测试工程师，除了关注测试执行相关的时间节点外，我们也需要关注和跟踪项目维度的所有关键时间节点。”
一、探索型测试排期
如图 1-2 所示，在探索型测试排期中，我们需要关注的时间节点增加到 14 个，包括需求计划评审时间、研发方案计划评审时间、开发计划开始时间、开发计划提测时间、测试计划开始时间、测试计划完成时间和需求计划发布时间 7 个计划时间节点，同时包括以上七个节点的实际完成时间节点，共 14 个节点。实际工作中，计划时间节点和实际完成节点很多情况下都会不一致，且大多数情况实际情况会晚于计划的时间，这里简化为一致标记在一个时间节点上。
图 1-2 探索型测试排期时间节点
为什么需要增加自己的工作量去关注和跟踪这些时间点呢？
首先，在讨论做这件事的意义前，我们先分享下不做这件事可能的后果。对于一个需求或者一个项目来说，项目的发布时间一般是不能延期的，如果开始测试前的任何一个时间节点发生延期，最后为了保证项目按时上线，只能压缩测试的时间。这样的后果就是测试只能加班，并且，如果由于测试时间被压缩导致测试不充分从而引起的线上事故还是得由测试人员承担事故责任。
其次，我们来讨论下做这件事的成本。做这件事的成本并不高，我们只需花几分钟的时间提前咨询下相关负责人的计划完成时间和每天的进度，并整理好各个时间节点计划时间点和实际进度后，同步给项目群。
最后，我们再来讨论做这件事的意义。一方面，如图 1-3，项目过程中一旦有前置时间节点出现延期情况，我们就可以提前识别和暴露风险。另一方面，从项目维度识别和跟踪各个节点的进度，不仅可以提升我们对项目整体的认知，也可以逐步提升测试人员在团队中的影响力和话语权。
图 1-3 探索型测试排期模版
二、总结
为了保障项目按时按质发布上线，也为了让我们自己按时下班还能不断成长，我们应该学会整理和跟踪探索型测试排期。如果项目中有项目经理或者其他人担任起每个需求进度的跟踪工作，那你就可以花更多的精力去提升自己的其他方面，如果项目中并没有人对你负责的需求进度进行跟踪，那你就要承担起这个工作。因为做这件事并不难，还能帮助你成长。
相关引文：《漫谈测试成长之探索——测试文档》
原文地址：《漫谈测试成长之探索——测试排期》