lsekfe 发表于 2013-10-9 10:27:57

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

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




获奖名单
奖项获奖名单奖励答案链接

一等奖土土的豆豆 50元京东礼品卡#4
二等奖      hotivy 300论坛积分#2
三等奖      Dreambeach 100论坛积分 #12

hotivy 发表于 2013-10-9 11:22:22

本帖最后由 hotivy 于 2013-10-9 11:57 编辑

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

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

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

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

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

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

千里 发表于 2013-10-10 00:40:29

本帖最后由 千里 于 2013-10-18 13:09 编辑

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

土土的豆豆 发表于 2013-10-10 09:34:22

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

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

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

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

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

希望其他大神补充,指正!

hotivy 发表于 2013-10-10 17:29:54

回复 3# 千里


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

千里 发表于 2013-10-11 07:59:19

回复千里


    跟你这个一比,我觉得我就是个土匪层次。请教下,项目管理方面的书籍会有助于这方面理 ...
hotivy 发表于 2013-10-10 17:29 http://bbs.51testing.com/images/common/back.gif


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

千里 发表于 2013-10-11 08:07:40

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


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

fetch 发表于 2013-10-11 15:10:19

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

城邦 发表于 2013-10-11 15:46:10

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

千里 发表于 2013-10-11 20:53:52

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


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

mpas 发表于 2013-10-12 08:52:31

回复 4# 土土的豆豆


    学习了。

Dreambeach 发表于 2013-10-12 15:27:35

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

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

yuna4217 发表于 2013-10-12 17:07:15

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

在心中 发表于 2013-10-16 10:43:21

{:3_69:}我是来学习的。

chenxl624 发表于 2013-10-18 12:45:07

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

挂名管理 发表于 2013-10-18 12:52:25

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

wangk1 发表于 2013-10-20 20:17:53

我是来学习的。:)

千余同 发表于 2013-10-21 16:45:48

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

qinxin 发表于 2013-10-21 18:08:48

各位大拿都好厉害,我是来学习的:loveliness:

FighterLqs 发表于 2013-10-22 14:30:01

强势围观
页: [1] 2 3
查看完整版本: 紧急情况下压缩了测试周期应该怎么办?(获奖名单已公布)(2013.10.31)