提问：紧急情况下压缩了测试周期应该怎么办？
回答：本期话题分几个要素点，我将根据命题划分的几个关键词：紧急情况，压缩，测试周期，来一起分析探讨。
项目中难免会碰到很多“紧急情况”，如：
1、需求变更
客户是善变的，我们必须伺候好客户，不是么？没有任何理由，他们要变更需求，一般情况下，最为乙方、丙方只有服从。
2、项目外包
很少有人碰到过吧？不过的确存在！项目进行到一半时由于自身团队或者高层决策、成本等方面上的要求，直接将项目外包出去，或者重新让一个项目团队接手。
3、开发设计架构存在明显严重缺陷
显然，架构师、项目经理等没有在前期做好评审和确认，但是很多项目，尤其是政府项目团队成员很随意，反正是有扶持款项。但这不是质量低下的理由！
4、不确定因素造成人员减少
如核心员工跳槽离职、女同事怀孕、家里生老病死等。
5、客户要求提前上线
在交付阶段，再次回到客户，他是老大，出钱的，给项目的！甲方要求提前项目上线，这不得不加快进度，不是么？
关键点把握——“压缩”
综合上述我列举的几个原因，在项目决策和进度上已经批复下来，我们必须得“压缩”进度安排。这里明显不存在沟通、协商的必要了，或者说与相关部门、人员沟通/协商无效了。
但是对于我们测试团队的“测试周期”，个人认为，有必要澄清或者继续不断与相关涉众进行沟通和协商！毕竟整个周期被砍，直接最大影响的是我们测试部门同事！
这里根据之前列举的5大理由，我会有侧重地整理下解决方案：
1、需求一旦变更，项目团队前面阶段也肯定有影响，开发需要重新设计编码，然后才是到测试阶段。由于需求变更是客户方提出的，我们有权利去交涉争取最长“测试周期”。这里作为测试经理必须和项目经理统一战线，和客户方达成共识。因项目后期客户自身提出的临时需求变成要求，本不在合约范围内，所以综合已有的项目计划和人员安排，在强制要求“压缩”进度、或者保证原有进度的情况下，个人认为必须给客户列举出详细的测试风险和影响要素。让客户方明确在进度被压缩的前提下，我们能保证的质量效果和最佳状态！知道风险是多方面必须一起承担的。
2、项目突然被外包给别人，有点不可思议！但是整个项目被第三方接手，这里的交接情况，主要是新项目组对需求的快速把握、理解，开发方对项目架构、设计及代码的熟悉都是不得不去考虑的。这样对于测试团对来说，只能延后开始执行测试时间点，那势必得把握测试要素的重点。个人建议按测试优先级、功能重要等级进行分类和划分，给客户方一个明确能保证质量的测试业务点清单。毕竟不可能在短时间项目被重新分包情况下，让测试团队控制什么进度来交付产品/项目。这个是整个项目进度的问题。
3、开发设计有严重问题。这个是自己团队得承担的责任！但是也因此影响到了测试部门人员。我们在开发人员紧急处理问题时，可以同步参与单元测试、接口测试等。因为已经大架构上错误了，测试人员协助开发人员一起确保系统设计、搭建没有问题，其实是不能再出问题！
4、非受迫性减员很普遍，但是各项目组或者总的测试团队负责人/测试项目经理必须分配好冗余资源进行补充，自己得多承担责任。作为缺岗人员的备份者，更加要协调好剩余同事的任务安排，稳定军心。
5、客户要求赶工上线，正常情况下不能保证质量是否完全可靠，同问题1，得让他们承担接受潜在风险！上线交付是个很严肃的过程，对系统功能、性能、安全、稳定性，软、硬件环境要求必须都满足上线的前提，才能正式交付，客户在计划外要求提前上线，除去自己业务方面需求，没有对项目团队有啥合理理由或者要求，我们作为测试团队，得把握其上线要求的最佳业务点，如某个功能模块一定要运行正常稳定，有侧重的去测试该部分，若他们可以接受条件的话。
其实上述方面我还是侧重与责任方进行交流沟通！虽然已经被压缩了进度，但有些情况必须阐明，才能安心工作，对于测试部门，测试经理也有义务进行责任承担的同时，给予同事们最大程度保护！
对于传统的加班加点，加人加米等方式，这里我其实不想多说，因为这些都是非正常的要求，才称之为“紧急情况”，所以除去那些人力、费用、资源等成本不说，在项目进度，这里主要是测试进度加快情况下，只能先理清思路，针对不同要求去协商并沟通，争取最佳的效果吧。尽可能保证项目在预期内打到理想的最好质量状态。
我个人是没有见过被压缩进度下，又要做到很好，又要满足各种要求的！这不现实！这里只是给出最可能的、理想的、较好的处理方式和技巧而已~
希望其他大神补充，指正！
最新内容请见作者的GitHub页：http://qaseven.github.io/