QA常常需要面临的排期问题
下面是通常会面临的项目场景了：
PM：涉及核心模块改动，由于XXX原因，需求想尽快上
开发人员：这个改动简单，1天肯定能搞定
QA：这个测试由于涉及核心功能改动，需要回归，需要2天时间
于是当QA说出需要的测试周期时，PM/开发人员通常会产生疑惑：改动特别小，其他的都没改，不需要测试，只测试XXX就行了，不需要这么长时间吧？每每听到类似的观点，QA同学们是不是都有种欲哭无泪的心情了。
QA在排期考虑时的几点困惑
1、开发人员评估1天，但按测试时间是开发时间的一半，感觉不够，但一时又想不出好理由
2、开发人员说只改动了XXX功能，但自己本身又不了解影响范围，无法很好做出评估
3、测试用例数量不多，但执行过程中造场景、执行很费时，按原来的时间上线感觉很赶、有风险，如何抛出
4、测试中发现了大量问题，虽然及时修复，但感觉风险挺大的，时间不太够用
QA排期时需要考虑的几个问题
- 不同的项目，不同层面的改动，应该怎么去估时？
- 在产品、开发人员质疑我们的时候，该如何回应？
- 在评估时，如何有理有据给出合理的依据？
- 如何在评估时，将项目保质保量上线的风险考虑进去？
- 合理的估时排期对项目质量、团队合作有什么影响？
排期时应该考虑哪些方面
- 需求的规模，是否新需求，还是日常修修补补的维护？
- 后续需求变动的可能性、对研发、测试的影响大小？
- 研发团队对需求实现轻车熟路，还是需要和第三方密切对接，还是需要边调研边开发？
- QA人手是否老手，还是新人需要有一个”预热期“？
- QA对需求测试是否轻车熟路，测试环境/数据是否准备就绪，还是需要对接准备？
- 根据以往经验，项目buffer时间需要多久？
- 产品人员、开发人员、测试人员团队合作默契如何？
- 线上发布有问题，回滚成本有多大、故障降级对用户影响程度如何？
排期是在时间、人力、成本、风险、质量之间进行充分平衡、评估后，并且在团队人员中达成共识的结果。所以，无论是测试周期是开发周期的一半，还是测试时间需要多于开发时间，这都是一个充分平衡的一个结果而已，而具体要如何平衡，就需要集合团队人员的智慧了。