背景
业务线为了小步快跑，加快交付频率，实行了周迭代，以单周或者双周的周期完成评审、开发、测试和上线。
实行了一段时间以后，遇到了一些新的挑战：
- 故事拆小，启动的项目数变多，可能1个测试要介入到多个项目，虽然推动开发进行自测，但仍有不少项目需要测试提供用例给开发。
- 整体研发周期缩短，节奏较快，投入在前期评审和设计的时间较短，后期发现问题容易造成返工和浪费。
所以针对以上两点，期望尽可能的提高测试对项目介入的覆盖度——能够接较多的有质量风险的需求，至少提供用例保障 ；同时能够提高研发效率尤其是前期评审和设计的效率——不返工，周期的确定性，利于排期和资源流动
我们发现：只有真正开始测试设计，才能更好的发现业务和逻辑上的问题，所以尽可能早开展测试设计能带来一定收益；同时，尽可能早开展用例设计，能够增大测试用例设计的时间窗口，缩短技术方案评审后到完成用例所需的周期，提高承接项目用例编写的数目。
实践
我们的实际做法是：需求文档产生后立即开展测试设计，在技术方案出来前基本完成用例设计，在技术方案评审后进行一些补充，然后快速进行用例评审和交付用例。
测试介入的越早，获取到的信息越少，如何通过较少的信息去产生较好质量的用例是一个难点。要解决这个问题，我们手上有两个较为有利的条件：
- 需求颗粒度小，需求更为明确，能够通过需求完成主体用例的编写
- 之前导购敏捷左移实践积累了一些经验，有些最佳实践指导。显卡界也面临类似的问题，通过低分辨率画质重建成高分辨率图像来提高画面帧数和游戏性能，采用的办法大概是通过算法去预测和脑补出缺失像素图像。我们也可以参考类似的做法，利用基础业务检查点和设计参考点尽可能完善我们的测试设计。
所以为了确保用例设计的完备程度，核心思路是根据需求文档完成主场景用例编写，后续通过迭代改进的方式逐步去完善用例，在每次设计过程中，通过以前的敏捷左移实践去填补测试用例的设计点。
具体做法：
- 阅读需求文档，初步看下是否有大的问题，找产品进行确认，之前总结了一些需求评审check的套路和方法，如需求评审套路。
- 根据需求文档开始设计场景用例，可参考业务需要关注的测试场景、测试方案参考点等实践文档，查看基本的场景下是否有问题和疑问，有的话可以留空标注，需求评审会上对齐。
- 对于边界场景、异常场景等技术实现相关的场景可以做基本设计技术方案后优化，或者跟开发沟通确认是否有这部分的设计，推动开发完善设计。
- 技术方案评审后进行最终用例的完善，最后进行用例评审。
在目前这套流程中，和传统用例设计模式相比一个较大的区别是：之前测试更多的是等产品、开发准备好设计文档，被动的从中接受信息，但现在更多的是需要通过沟通来获取信息，在这过程中，一方面测试的心态更多积极主动，对项目更具备把控力；另一方面能够推动开发、产品提前思考测试提出来的问题，在设计时就能澄清一些可能的问题，减少后期用例评审或开发阶段可能出现的重复沟通和方案修改。
结果
实践了几个项目，个人的收获：
- 前期能够发现更多的问题，其中有些模糊点涉及外部是会影响可行性且需要提前沟通确认的，提前提出减少了较多的不确定性和沟通成本。
- 工作量前移，技术方案评审后能够更快交付用例，70%左右的用例都可以在技术方案前ready，一般单周的项目开发时间1-2天，双周3-4题天，基本能够在联调前给出用例。
- 掌控性更强，一般在技术评审后会大概制定下里程碑，有了基本的测试用例和设计，对项目工时、风险评估更准确些。