如何制定合理的分批提测计划

公司采用敏捷开发模式， 两周一个迭代周期。 现实中经常会遇到跨敏捷组或者迭代周期的大项目， 有时候为了测试尽早介入， 或者是为了提早交付， 研发团队会采用分批提测的方案， 来提高项目并行度， 缩短项目周期。

分批提测的优缺点

优点	缺点
因为已经开发完的部分可以先提测， 所以可以尽早发现问题	回归测试会有重叠
及时调整需求	由于和研发下个周期的开发时间重叠， 所以导致修复bug时间比较长
尽早发现问题	测试时间长度错觉

所以在拆分一个需求， 制定分批提测计划的时候， 需要注意以下几点：

1. 每次提测的内容必须是独立的，有价值的，可讨论以及可测试验证的；
2. 内容平均，确保每次提测的内容在迭代的测试预估时间内；
3. 高风险优先，尽早发现风险和问题是质量保障策略中重要目标；

分批提测拆分方法有以下几种：

1. 从上往下： 按照数据链路， 先完成上游逻辑提测 功能优先： 先保障功能链路的走查， 再验证性能， 安全， 兼容等指标
2. 从后往前：项目如果涉及前后端开发， 后端稳定接口可先提测 二八分发， 研发工作量投入80%的模块最好拆分到前批提测，这样可以预估项目质量，测试内容，尽早调整项目进度
3. 先中间后两边： 先保障核心功能和主场景提测， 异常流场景可以稍后
4. 少走回头路， 逻辑确定的模块优先提测，这样可以减少因不断修改带来的重复回归
5. 金钱至上， 作为TOB服务， 要优先满足顾客付费模块