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