点我在「喜马拉雅」收听本篇对应的完整音频分享本期嘉宾鼎叔 @dylan.zhang ：互联网/通讯行业大厂技术总监，高级架构师，测试专家，敏捷教练。公众号「敏捷测试转型」作者，在 TesterHome 论坛著有同名专栏《敏捷测试转型》。
先来三个链接，大家各取所需：
点我在「喜马拉雅」收听本篇对应的完整音频分享
做项目必然要面对交付的风险，测试团队经常被推到风险 “兜底人” 的角色——且不论这种做法是否正常，但确实存在。因为测试阶段之前的环节延误，而导致留给测试的时间变短的情况也经常发生。
在这类事情发生后，只要我们已经做好 “分内” 之事，尽到专业精神，实际上并不会承担太大指责。哪怕项目失败了，也很少真的归咎于测试。
“尽早” 是多早？这时候还在项目规划中，开发可能还没开始写代码。我们在这个阶段就要考虑好，需要多长时间留给测试独占。
什么叫做 “独占”？就是在开发写完代码并且正式提测后，单独留给我们开始测试到最后完成测试的一段时间。
一方面我们要公开透明地给出测试所需的独占周期，如果测试时间会被压缩，也好明确能接受的最短时间。
比如，预估的测试独占周期是七天，但是产品或者项目经理说只有五天测试时间。我们可以只用五天来测试，但是要公开一份项目关键角色签字承认的风险声明：通过倒排，把原本七天的工作按照优先级放在五天来做；如果发生一些意外或者发生一些问题，那么有可能要放弃优先级低的两天的工作，或者是降低质量。如果像这样规划好，在这五天保证好基础的质量，就算上线后有一些小 bug、小故障，我相信大家也是可以接受的。
另一方面要考虑，测试独占周期里面的所有测试工作，是不是只能按顺序 “串行”？
比如说，我们的测试工作包括兼容测试、性能测试和功能测试，在时间有限的情况下，这些不同类型的测试工作是否可以并行，在短时间做好更多的工作。
到底有哪些事情可以左移呢？以我自己现在所做的大型项目为例，可以左移的事情大概有这些：
1）通过提前计划测试范围和测试策略，估算所需测试人力，预测后期可能需要借调多少测试人员
有一些大型项目，在测试阶段会很慌乱的一个原因就是，突然临时找了一堆人来协助测试。如果临时抱佛脚，虽然人力增多，但是可能比原来的质量更差。作为测试负责人，当我们预见到人力有可能不足的时候，就早一点把可以帮助测试的人力卷入进来，提前告知他们后期有可能要来协助我们做测试。可能这些测试人员手上已经有其它项目要跟，我们至少可以先给他们分享一些项目资料——比如已有的测试资料、测试用例和测试策略等知识，让他们先从学习的角度做好准备——后期就能更好地缓解测试资源的不足。
2）把一些专项规划提前做好
什么专项呢？比如说测试环境。
越是项目时间紧张时，测试数据和测试环境经常是导致 “意外” 发生的主要原因之一。怎样提前构建好测试环境呢？其中一个做法就是，让开发在我们的环境里做自测。有的公司会实行 show case：在开发提交集成测试前，要当着测试、产品和 leader 的面，做一个代码能够正常运行的的 show case；开发同学为了保证自己的代码在 show case 时跑通，会自觉做大量的环境搭建和数据准备，以及自测。
还有比如压力测试、安全保障等方向，也可以提前规划：要不要做，需要什么样的环境来做，具体包括哪些方面等。提前列好清单，安排好负责人。
3）让技术能力比较强的测试同学参与 code review
如果测试同学参与 code review，至少就能够知道这一次版本发布中提交的代码跟上一次比，主要的差异是什么，开发到底引入了哪些变化。那么，这些变化可能就是这次测试的重点。如果 code review 后发现，很多东西没有变更，那没有变动的部分，在测试时投入的精力就少一点，只做一些经典的 regression。而是把更多的精力放到 code review 发现的风险点上。
4）预设应急响应 SOP
应急响应的 SOP 需要关注的点包括：一旦发生了线上异常，谁做第一步的追查，告警要发送给谁，什么样的角色小组要做回滚，要采取什么措施进行止损等。
综上所述，围绕着测试时间不足的问题，我们要梳理好风险清单，针对每一条风险都要有一个结论。常见的结论包括：首先明确，如果某个风险发生了，对业务的影响大不大？假设影响并不大，我们希望它尽量少发生，但是真的发生了也不会有很严重的后果。第二点是指定一个责任人或者一个角色，处理风险。第三点是规划好缓解的措施，比如可以提供支持的后备人力和团队。第四点是做好监控，一旦发生我们再响应。
相信如果我们做到这些，加上前面所说的在项目中公开测试独占周期、测试方案和计划，就已经在能力范围内做到足够专业，哪怕项目上线后真的有问题发生，也不会有人对我们做太大的追责。
未完待续
左手管理右手技术，测试团队管理者应该如何做好自我发展？
做员工绩效考核时，怎样给出合理的低绩效？
