在大部分项目中，里程碑计划是通过上线日期倒排，而不是结合具体项目范围进行评估得出，并且系统测试阶段通常属于研发流程的下游，上游的进度延误直接导致下游的时间被压缩，因此测试同学经常会面临测试周期压缩的问题。
在测试周期被压缩的情况下，按照原计划完成相应测试工作已不可能，那么怎么应对呢？
「 改变测试方法和技术提高效率 」
比如更早地运行自动化测试，尽量在前期发现问题；使用自动化脚本进行回归测试，缩短回归测试时长。
原计划可能是手工执行回归测试，如果测试周期紧张，可以借助脚本完成该部分测试任务。
这就要求平时要做好单元测试脚本和系统测试脚本的编写和维护工作。
「 加班赶工 」
考虑在原安排的人员加班的情况下，能否完成原计划的测试工作，包括工作日加班和周末适当加班。
如果加班，注意要用适当的激励方式和员工福利，比如申请项目奖金、加班费、用项目经费请大家喝下午茶、吃饭聚餐等。
加班要适当，超负荷的加班会反而导致工作效率的下降。
「 争取更多/更有效的测试资源 」
想办法在数量和质量上争取测试资源，一个方式是增加其他测试人员，或者申请开发、产品人员加入执行测试，这要注意测试用例的分配。
另一个方式是申请调配对该系统/模块最熟悉最有经验的测试人员加入项目，有可能原先该同学被安排在同时进行的其他项目中，如果遇到紧急情况可以尝试向上级申请，将有经验的同学调过来。
注意不能盲目增加测试资源，加入对系统不熟悉的人员、新人、临时聘请的外包人员反而拖慢原有的测试进度。所以平时分配需求时要注意，一个模块或者系统最好有两个以上熟悉的人，做好人员储备。
「 缩减测试范围 」
如果通过加班、增加资源的方式无法确保在既定时间完成既定任务，则考虑缩减测试范围。
这里不是指部分模块不进行测试直接投产，而是由项目经理评估优先级较低的功能模块，和业务沟通是否可以放到下一版本投产，优先确保重要的功能稳定上线。
比如针对电商系统，可以先将积分功能关闭，后期安排时间对积分功能进行充分测试后再投产。这要求设计时注意各功能的配置，可以实现自由开关。
「 明确测试用例优先级 」
如果测试时间紧张，则优先执行优先级高的测试用例，将特殊场景和异常场景遗留后期再安排时间执行，这就要求设计测试用例时注意对测试用例分层，并且在测试报告中要说明未执行的用例。
「 加强质量和进度把控跟进 」
越是测试时间紧张，负责人越是要加强跟进和把控，及时监控测试质量和效率，规避和纠正问题，避免出现严重偏差。
「 记录相关风险和建议 」
在测试报告中明确测试范围、未上线功能、未覆盖的测试用例以及存在的风险和应对措施。
如果有未执行的测试用例，需要后续安排测试时间和资源投入处理。
「 做好测试总结 」
最后的总结容易被遗忘。针对测试周期压缩的应对，有哪些做的好的和做的不好的地方，组内可及时总结，吸取经验教训，之后遇到类似情况才可以从容应对。
「 前期的把控 」
大家都知道测试不应该在系统测试阶段介入，在需求阶段、设计阶段、编码阶段等，测试同学要发挥测试的优势，提前发现可能存在的缺陷，规避相关问题和风险，提测质量上去了，测试过程才能高效。否则项目一团糟，代码质量一团糟，即使测试阶段投入再多的人力和资源，也无事于补。
测试同学遇到测试周期压缩的情况时，要明确优先级。不仅是功能的优先顺序，还有用例的优先顺序，如果子弹少，就更要精准地打，集中主要精力处理重要任务，同时还要克服焦虑。
如何应对测试周期压缩也是如何平衡好时间、成本、范围、质量的关系，和在项目各阶段考虑投入产出比是一致的。
其次，从侧面可以看出，平时做好基础工作才能从容应对特殊情况，比如系统设计、单元测试、测试设计、自动化测试、人员储备等，大家总感觉项目紧张，这些不重要的工作可以放一放，规范可以缓一缓，殊不知其实是降低了交付效率，同时也让项目陷入一个恶性循环。
文章来源：网络 版权归原作者所有
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处理
网友评论