本文章转载于搜狗测试
需求变更处理遇到的坑
需求变更是项目迭代中常见的环节，从项目的角度考虑，有些需变会对项目带来很大的收益。小编所在的项目中，也会遇到需求变更的情况，结合之前的经验，小编整理了如下需变处理不到位而遇到的坑，请大家绕坑而行。
问题一：二轮测试中，小A负责的模块需求变更，需变发出后，未经三方确认评估。小A介入测试时，发现改动范围较大，之前测试的功能需要重新回归，对于二轮阶段来说，项目迭代速度及质量均存在风险。问题三方确认后，发现此需求变更的优先级不高，鉴于后期版本迭代的控制，代码进行了回滚。
总结：对于需求变更，需三方确认沟通，对于需变的合理性、需变效果要求、需变带来的代码改动成本、测试回归成本等均需进行评估确认，结合三方的意见，最终决定是否进行需求变更。
问题二：小A在主线版本测试过程中，负责某个模块的需变，需求变更经过了三方统一的评估且达成一致，因优先级不高，未能及时的更新至排期，导致需变的任务遗漏。
总结：需变往往是模块功能的优化补充，测试人员在高优先级忙于其他任务的测试，很容易将需求变更的任务遗漏。需求变更确认后，需及时的更新至排期中，避免遗漏。
问题三：二轮测试中，小A负责某个模块的需变，因需变业务逻辑相对简单，小A直接进行的测试，而未进行用例设计的编写和评审，导致场景考虑不全而出现线上Bug。
总结：遇到需求变更后，尤其是二轮期间，测试人员经常会遗漏用例设计及评审环节，导致未严格按照测试流程执行，对于版本的质量存在风险。所以，针对需求变更，不论测试在什么阶段，均需要严格按照流程规范执行。
需求变更的规范模板
针对如上遇到的坑，小编为大家提供了如下需求变更的模板，产品/开发在需求变更时，可参考如下模板发送邮件，减少沟通的成本及潜在的质量风险。
需求变增
项目版本Android_V5.7.0版本
功能名称推送通知
变更类型□新增 ■变更 □内部改进 □产品缺陷 □其他
需求优先级□高（基本的）■中（条件的）□低（可选的）
效果要求□强（完美实现） ■中（实现即可） □弱（可容忍缺陷）
变更内容xxxxx
变更原因xxxxx
连带影响模块通知
变更风险xxxxx
产品文档（说明：可为相应的SVN链接或邮件附件）
提出日期4/10/2017
Deadline4/21/2017
变更审批人项目经理、产品负责人
变更执行人产品、开发、测试
是否需要重新测试是/否
申请人员xxx
需求变更的处理流程
需求变更在流程上，需三方确认，三方达成一致后，测试人员对于需求变更的处理需严格按照测试流程规范走，避免质量上的风险。具体流程规范可参考如下：
需求变更的总结思考
需求变更是不可避免且有意义的，但是针对频繁的需求变更，会增加开发、测试的成本，测试人员持续的总结思考，做到提前的预知和规避。
1.针对需求变更，需要评估需求变更的合理性，并总结是否提前可预知。最好能够把需求变更的时间提前至需求讨论会阶段，避免对项目后期造成的压力。
2.针对已发生的需求变更，需要记录，上线后与产品一起分析总结，持续优化可提前预知的需求变更。
