紧急情况下压缩了测试周期应该怎么办？（获奖名单已公布）（2013.10.31）

lsekfe

本周的问题为“紧急情况下压缩了测试周期应该怎么办？”
此话题由会员junell提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	土土的豆豆	50元京东礼品卡	#4
二等奖	hotivy	300论坛积分	#2
三等奖	Dreambeach	100论坛积分	#12

hotivy

加班！哈哈，这个国产IT界出现频率最高的词汇之一。
   
    众所周知，时间和质量是成反比的，面对压缩的测试时间，应该具体问题具体分析，积极协调资源并且加强风险管理。个人想法如下：

   1、增加人员
    如果有完整的测试设计、执行方案，可以通过增加执行人员的方法来加快测试进度，由于测试资源完整度高，可以考虑加入“非本项目”人员执行测试、记录bug，从而弥补时间问题。不过对于“非本项目人员”同时也会带来工作效果不佳、人员不稳定、信息安全等问题，测试经理应加强测试结果的监督。

    如果没有完整的测试设计，增加编外人员反而得不偿失，系统培训、业务理解等会占用很多时间。这种情况可以考虑增加项目相关的设计、开发人员参与测试，但要注意不要测试自己的开发的模块。与项目经理沟通协调相关人员。

   2 重新制定测试策略（裁剪测试范围或测试力度）
   在“人员”不能增加的情况下，需要积极与项目组协商“变更测试范围”或者“削弱测试力度”。至于变更多少，要根据项目性质、客户情况而定。有的项目需要核心功能不出问题，有的项目则是功能大面上不出毛病即可。测试经理可以依照不同项目情况来制定新的测试策略，并且获得项目干系人的认可。
   我个人还是偏重“要么不干，要么干好”的原则，从经验上看这个方法也适用于多数项目，很多客户可以忍受时间压缩后在“非核心”功能上出现bug。项目经理顺利的完成核心功能演示，对他的后期谈判也是很大的帮助。
  如果还在项目周期内，则可以考虑部分模块放到下一轮迭代测试，具体哪些模块下放需要与开发、设计人员商讨。

   3 加强风险管理
    对于压缩周期带来的风险，应及时整理，全面考虑，积极上报。风险也是测试协调资源的有力武器之一。风险处理发现，还要跟踪，不能发现完后就置之不理。

    以上方法不是独立使用的， 可以根据实际情况交叉运用。不要给手下小弟们太多压力，加班时买些零食、水果给他们补补吧。

千里

这是一个典型的项目管理中时间管理的问题，在测试过程中仍然可以应用项目管理的方法进行管理。
一般碰到该问题，首先想到的是提报风险，将风险作为最高等级来汇报。并且跟各干系人左沟通右沟通，希望争取更多的时间，希望得到应有的测试周期。
而结果一般来说却是风险汇报了，领导也知会了却没有任何指示，也就是按既定方针办。测试负责人死缠烂打、满地打滚也没有争取到半点额外的时间。
但测试还得继续，这时候能怎么办？还能怎么办呢，加班呗，做不完也硬着头皮上呗，不然还能怎么办？
这里我不是说不要汇报风险，不要去尽量沟通。而是风险和沟通做了还不够，需要其他手段来实实在在摆平这个困境。
方法有很多，一般来说有两种方法：赶工和快速跟进。这是项目管理里面的直接所提到的方法；
赶工很明显是加班，通过额外的劳动得到更大的产出。这时候需要注意一点是在关键路径（重点工作）上加班，否则可能陷入加班的无底深渊。
快速跟进是将各个子任务的衔接时间缩短，将可以同时进行的任务尽可能安排同时进行以加快测试任务的开始，同时也可以提早任务的结束。
另外还有加人，加人的问题不需要多说了，相信大家也懂的。
---------------------------------------------------------------------------------------------------------------------------------------
以下来自于个人经验：
在管理上，最拖延进度的却是时间的浪费，特别是管理者对时间的浪费。若能减少对时间的浪费，能极大的提高工作产出。
这中间属项目团队的内部沟通和外部沟通，工作任务安排的不合理对时间的浪费比较明显。
在紧急情况下，最重要的我认为还是需要加强控制，高效沟通，所谓忙得出乱。
越是紧急情况下越是需要一个强有力的领导来带领团队，减少时间浪费，让工作更为有效来渡过难关。

土土的豆豆

Agree 楼上千里兄……“楼层越高中奖率越高” 咔咔~
开个玩笑~
言归正传，本期话题分几个要素点，我将根据命题划分的几个关键词：紧急情况，压缩，测试周期，来一起分析探讨。

项目中难免会碰到很多“紧急情况”，如：
1、需求变更
客户是善变的，我们必须伺候好客户，不是么？没有任何理由，他们要变更需求，一般情况下，最为乙方、丙方只有服从。
2、项目外包
很少有人碰到过吧？不过的确存在！项目进行到一半时由于自身团队或者高层决策、成本等方面上的要求，直接将项目外包出去，或者重新让一个项目团队接手。
3、开发设计架构存在明显严重缺陷
显然，架构师、项目经理等没有在前期做好评审和确认，但是很多项目，尤其是政府项目团队成员很随意，反正是有扶持款项。但这不是质量低下的理由！
4、不确定因素造成人员减少
如核心员工跳槽离职、女同事怀孕、家里生老病死等。
5、客户要求提前上线
在交付阶段，再次回到客户，他是老大，出钱的，给项目的！甲方要求提前项目上线，这不得不加快进度，不是么？

关键点把握——“压缩”
综合上述我列举的几个原因，在项目决策和进度上已经批复下来，我们必须得“压缩”进度安排。这里明显不存在沟通、协商的必要了，或者说与相关部门、人员沟通/协商无效了。
但是对于我们测试团队的“测试周期”，个人认为，有必要澄清或者继续不断与相关涉众进行沟通和协商！毕竟整个周期被砍，直接最大影响的是我们测试部门同事！

这里根据之前列举的5大理由，我会有侧重地整理下解决方案：
1、需求一旦变更，项目团队前面阶段也肯定有影响，开发需要重新设计编码，然后才是到测试阶段。由于需求变更是客户方提出的，我们有权利去交涉争取最长“测试周期”。这里作为测试经理必须和项目经理统一战线，和客户方达成共识。因项目后期客户自身提出的临时需求变成要求，本不在合约范围内，所以综合已有的项目计划和人员安排，在强制要求“压缩”进度、或者保证原有进度的情况下，个人认为必须给客户列举出详细的测试风险和影响要素。让客户方明确在进度被压缩的前提下，我们能保证的质量效果和最佳状态！知道风险是多方面必须一起承担的。
2、项目突然被外包给别人，有点不可思议！但是整个项目被第三方接手，这里的交接情况，主要是新项目组对需求的快速把握、理解，开发方对项目架构、设计及代码的熟悉都是不得不去考虑的。这样对于测试团对来说，只能延后开始执行测试时间点，那势必得把握测试要素的重点。个人建议按测试优先级、功能重要等级进行分类和划分，给客户方一个明确能保证质量的测试业务点清单。毕竟不可能在短时间项目被重新分包情况下，让测试团队控制什么进度来交付产品/项目。这个是整个项目进度的问题。
3、开发设计有严重问题。这个是自己团队得承担的责任！但是也因此影响到了测试部门人员。我们在开发人员紧急处理问题时，可以同步参与单元测试、接口测试等。因为已经大架构上错误了，测试人员协助开发人员一起确保系统设计、搭建没有问题，其实是不能再出问题！
4、非受迫性减员很普遍，但是各项目组或者总的测试团队负责人/测试项目经理必须分配好冗余资源进行补充，自己得多承担责任。作为缺岗人员的备份者，更加要协调好剩余同事的任务安排，稳定军心。
5、客户要求赶工上线，正常情况下不能保证质量是否完全可靠，同问题1，得让他们承担接受潜在风险！上线交付是个很严肃的过程，对系统功能、性能、安全、稳定性，软、硬件环境要求必须都满足上线的前提，才能正式交付，客户在计划外要求提前上线，除去自己业务方面需求，没有对项目团队有啥合理理由或者要求，我们作为测试团队，得把握其上线要求的最佳业务点，如某个功能模块一定要运行正常稳定，有侧重的去测试该部分，若他们可以接受条件的话。

其实上述方面我还是侧重与责任方进行交流沟通！虽然已经被压缩了进度，但有些情况必须阐明，才能安心工作，对于测试部门，测试经理也有义务进行责任承担的同时，给予同事们最大程度保护！
对于传统的加班加点，加人加米等方式，这里我其实不想多说，因为这些都是非正常的要求，才称之为“紧急情况”，所以除去那些人力、费用、资源等成本不说，在项目进度，这里主要是测试进度加快情况下，只能先理清思路，针对不同要求去协商并沟通，争取最佳的效果吧。尽可能保证项目在预期内打到理想的最好质量状态。
我个人是没有见过被压缩进度下，又要做到很好，又要满足各种要求的！这不现实！这里只是给出最可能的、理想的、较好的处理方式和技巧而已~

希望其他大神补充，指正！

hotivy

回复 3# 千里


    跟你这个一比，我觉得我就是个土匪层次。请教下，项目管理方面的书籍会有助于这方面理论的提高么？

千里

回复  千里


    跟你这个一比，我觉得我就是个土匪层次。请教下，项目管理方面的书籍会有助于这方面理 ...
hotivy 发表于 2013-10-10 17:29

    妈呀，土匪可是咱51testing的老师呢，这层次有点高。
言归正传，我一直关注项目管理方面的内容。体会很深的是软件测试是软件工程中的一部分，项目管理不仅在开发阶段适用，测试阶段仍然适用。
经过我的实际工作验证，特别是在测试团队工作过程中，项目管理的思想可以很好的应用进来。简单一点说，沟通、风险、时间进度、测试范围这些都在项目管理书籍中有讨论，而在测试管理中比较少被提起。
可以看看PMP的视频教程，我推荐吴永达的，相对而言通俗易懂。

千里

Agree 楼上千里兄……“楼层越高中奖率越高” 咔咔~
开个玩笑~
言归正传，本期话题分几个要素点，我将根据 ...
土土的豆豆 发表于 2013-10-10 09:34

    传说字数越多，中奖率也越高，哈哈。
这个问题上，咱们测试人员通用做法是你说的这样几种方法。也感觉到，你主要从风险控制上面着手，通过回避风险、转移风险和应对风险三种方式。
同时你在加班上面不愿意多说，都知道的这是最后不得已的手段恰恰又是使用得最多的手段。

fetch

1：调整计划，对测试任务进行权重和风险量化【模块所占验收交付的比例权重和优先级】
2：人员调配，专人做专事，提高工作效率
3：提高沟通效率，缩减沟通成本
4：增加人员，分工协作
5：加班加点
6：建立适当的鼓励和奖励措施，调动组员工作积极性

城邦

缩短测试时间，会造成质量风险的增加。这个时候做为管理的话，是需要赶工的，而赶工最有效的手段就是加班，而加班呢会使工作效率降低，降低了工作效率又会延长工作时间。所以这个问题需从几个方面来考虑，1、质量管理，要明确该项目的质量低线是什么。2、时间管理，充分的利用好每个工作单元。3、风险管理，这么做会有怎么样的后续风险。

千里

缩短测试时间，会造成质量风险的增加。这个时候做为管理的话，是需要赶工的，而赶工最有效的手段就是加班， ...
城邦 发表于 2013-10-11 15:46

    赶工要对关键任务进行赶工，否则效果不明显。

mpas

回复 4# 土土的豆豆


    学习了。

Dreambeach

首先明确缩短测试周期的原因，根据不同原因可制定相应的处理策略和方式，不能仅仅通过加班、增人简单应对。
如：
情况一：由于上游任务完成延期，为了保证项目原计划最终完成时间，而压缩测试的周期；
       这种情况，个人觉得测试不能无声、默默的接收测试周期的压缩，必须做出一定的反应，列出测试周期压缩情况下，可能出现的风险，跟对应项目的总负责（权利最大、有说话权的人）沟通协调。
            假如沟通协调结果是项目发布计划延期，测试周期保证正常时间，那是最好结果；如果沟通协调结果是项目发布计划无法延期情况，如果项目测试的范围及深度即测试策略不可变更（注：若可适当调整范围 和深度，从而可减少测试原计划的时间），那只能通过在团队人员可承受的加班方式，原团队人员加班人力仍不足，那就通过增加人员（由于新增人员可能对项目情况不了解，存在一定的风险）。

情况二：项目给用户使用时间提前；
        这种情况我们可以了解提前给用户使用的原因。如果只是试运行或给客户演示，并非实际的交付使用的情况，那我们可是更改测试方案、策略，先保证系统能够正常使用的验证即可，剩余的测试点给用户使用的同时，测试仍同步验证，如果发现bug及时更新用户现场。注意这种测试策略，最好事先跟开发协商沟通好，因为缺陷的及时修复需要跟开发的紧密配合。

yuna4217

在时间 人员 等方面一定的情况下，可以通过划分优先级的形式
按软件模块、功能或性能的优先级进行测试

在心中

我是来学习的。

chenxl624

来学习的。不过感觉加班是必须的。熟悉项目的人进行测试才保证质量，就算加人，没严格的用例也是很难保证的

挂名管理

通常做法不是加人，而且一时半刻也无法招聘到
只能重新确认测试策略，调整测试计划，整理功能优先级和测试先后顺序
然后加班加点！

wangk1

我是来学习的。

千余同

学习了，目前的项目也存在这个问题，一边是开发交付代码的延期，一边是客户要求交付上线

qinxin

各位大拿都好厉害，我是来学习的

FighterLqs

强势围观