51Testing软件测试论坛

标题: 紧急情况下压缩了测试周期应该怎么办？（获奖名单已公布）（2013.10.31） [打印本页]

作者: lsekfe 时间: 2013-10-9 10:27
标题: 紧急情况下压缩了测试周期应该怎么办？（获奖名单已公布）（2013.10.31）
本周的问题为“紧急情况下压缩了测试周期应该怎么办？”
此话题由会员junell提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

[attach]87522[/attach]

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

作者: hotivy 时间: 2013-10-9 11:22
本帖最后由 hotivy 于 2013-10-9 11:57 编辑

加班！哈哈，这个国产IT界出现频率最高的词汇之一。

众所周知，时间和质量是成反比的，面对压缩的测试时间，应该具体问题具体分析，积极协调资源并且加强风险管理。个人想法如下：

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

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

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

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

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

作者: 千里 时间: 2013-10-10 00:40
本帖最后由千里于 2013-10-18 13:09 编辑

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

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

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

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

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

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

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

作者: hotivy 时间: 2013-10-10 17:29
回复 3# 千里

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

作者: 千里 时间: 2013-10-11 07:59

回复千里

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

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

作者: 千里 时间: 2013-10-11 08:07

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

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

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

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

作者: 千里 时间: 2013-10-11 20:53

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

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

作者: mpas 时间: 2013-10-12 08:52
回复 4# 土土的豆豆

学习了。

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

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

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

作者: 在心中 时间: 2013-10-16 10:43

我是来学习的。

作者: chenxl624 时间: 2013-10-18 12:45
来学习的。不过感觉加班是必须的。熟悉项目的人进行测试才保证质量，就算加人，没严格的用例也是很难保证的

作者: 挂名管理 时间: 2013-10-18 12:52
通常做法不是加人，而且一时半刻也无法招聘到
只能重新确认测试策略，调整测试计划，整理功能优先级和测试先后顺序
然后加班加点！

作者: wangk1 时间: 2013-10-20 20:17
我是来学习的。

作者: 千余同 时间: 2013-10-21 16:45
学习了，目前的项目也存在这个问题，一边是开发交付代码的延期，一边是客户要求交付上线

作者: qinxin 时间: 2013-10-21 18:08
各位大拿都好厉害，我是来学习的

作者: FighterLqs 时间: 2013-10-22 14:30
强势围观

作者: 温柔狮子 时间: 2013-10-23 12:22
学习了，目前的项目也存在这个问题，一边是开发交付代码的延期，一边是客户要求交付上线

作者: 温柔狮子 时间: 2013-10-23 12:23
通常做法不是加人，而且一时半刻也无法招聘到
只能重新确认测试策略，调整测试计划，整理功能优先级和测试先后顺序
然后加班加点！

作者: 温柔狮子 时间: 2013-10-23 14:11
jjjjjjjjjjjjjjjj

作者: 刘毛毛 时间: 2013-10-23 17:03
加班。

作者: xingqi1181 时间: 2013-10-27 09:37
标题: 情人节
没有情人的情人节该怎么过得哦！

作者: reneelwj 时间: 2013-10-29 15:11
第一次回复问题我来说是我的看法
我觉得首先从项目管理的角度上来看这个属于风险管理和时间管理的范畴。当然牵扯到时间和质量的也必定会带来成本上的影响。
那从一个项目经理的角度首先要了解所谓的“紧急情况”
需求变更？由于之前计划delay导致后期赶工？客户要求提前？对于不同的原因项目经理应该采取不同的对应措施。
同时开展对应的风险预估，时间调整和成本估算
1.之前工作流的delay，调整测试介入时间，于测试经理沟通调整测试测量。
2.需求变更和用户要求提前，与客户做好沟通明确提前的风险，成本上的变化和可能存在的问题等，明确责任划分。重新制定开发和测试计划，测试前置，重新调配人员或安排加班。

那再测试方面的话。
1.如果是之前工作流中的环节有所delay，调整测试策略，重新制定测试计划，将测试工作尽量提前
2.用户要求提前：根据实际情况增加人手，安排加班，重新划分优先级和重要度重新制定测试计划和策略，当然如果这些手段依然无法完成，就要和客户重新讨论交付物的质量标准。
3.需求变更：这个问题就比较复杂牵扯到源头问题。测试阶段的需求变更是成本最大影响也是最大的。需要项目经理统筹各个部门进行项目中的协调分配和计划制定，牵扯到测试策略的重订，计划的重订。

作者: Remix_hero 时间: 2013-10-30 10:19
为嘛我和各位大神都不一样。
如果是因为开发团队拖延了整体进度，而领导不允许项目延期，要求压缩测试时间，我只会重新确定测试范围，明确测试的重点内容，保障在紧急时间范围内将能测好的几个点进行详细测试，而需要花费较长时间去进行的测试工作，我会选择性地放弃，在测试结束时提交的测试报告我也会明确说明本次测试的情况。同时也不会要求兄弟们加班，因为说实话，造成这种情况的责任不在测试，为何要让测试来承担后果。所以我会安排工作时间内进行测试，而是否加班，由我的兄弟们自己决断。
如果是因为客户方面有了变更而导致我们整体工作周期的缩短，那就是加班。

作者: caopengwww 时间: 2013-10-30 10:50
我认为最重要的是沟通！

作者: 千里 时间: 2013-10-31 13:23

第一次回复问题我来说是我的看法
我觉得首先从项目管理的角度上来看这个属于风险管理和时间管理的范畴。当 ...
reneelwj 发表于 2013-10-29 15:11

有项目经理的参与，这问题就好办多了。

作者: 千里 时间: 2013-10-31 13:23

第一次回复问题我来说是我的看法
我觉得首先从项目管理的角度上来看这个属于风险管理和时间管理的范畴。当 ...
reneelwj 发表于 2013-10-29 15:11

有项目经理的参与，这问题就好办多了。

作者: 千里 时间: 2013-10-31 13:23

第一次回复问题我来说是我的看法
我觉得首先从项目管理的角度上来看这个属于风险管理和时间管理的范畴。当 ...
reneelwj 发表于 2013-10-29 15:11

有项目经理的参与，这问题就好办多了。

作者: junell 时间: 2013-11-1 08:57
刚提出话题那会，我天天来论坛，看看有没有进每周一问，后来忙起来居然给忘记了。每一楼的回答，我都会认真看的，感谢版主，感谢每一层热心的观众朋友。真心学习，真心收藏。

作者: 中中 时间: 2013-11-1 16:48
学习借鉴了谢谢

作者: pcxty 时间: 2013-11-19 23:07
项目经理有责任，项目进度计划执行不得力，规定的里程碑没有完成规定的任务。
面对在既定时间点上交付的压力，只有加班或赶工。

作者: 千里 时间: 2013-11-20 09:17

项目经理有责任，项目进度计划执行不得力，规定的里程碑没有完成规定的任务。
面对在既定时间点上交付的压 ...
pcxty 发表于 2013-11-19 23:07

应该是感谢项目经理的参与和帮助

作者: fzu.134 时间: 2013-11-20 11:49
Gen jin zui jin ji de cases qi ta dou ke yi huo qi zai an paid gen jin

作者: xktkg 时间: 2013-11-30 15:28
不错,顶的人不多啊，快点继续

作者: VIP有风吹过 时间: 2013-12-24 10:32
分析的好到位，学习了

作者: 51testing-wn 时间: 2014-6-23 23:00

传说字数越多，中奖率也越高，哈哈。
这个问题上，咱们测试人员通用做法是你说的这样几种方法。 ...
千里发表于 2013-10-11 08:07

我想你要表达的是规避风险，不是回避风险吧？
规避是建立在风险分析和风险控制层面的，是面对即将或者可能发生的事情的一种积极响应；而回避是一种应付措施，是一种回应。

作者: 千里 时间: 2014-6-27 16:09

我想你要表达的是规避风险，不是回避风险吧？
规避是建立在风险分析和风险控制层面的，是面对即将或者 ...
51testing-wn 发表于 2014-6-23 23:00

哇，规避和回避一字之差原来含义完全不一样啊，中国汉字真是博大精深。

作者: louisken 时间: 2016-5-17 10:13
赞，学习了

作者: 海里的幸福 时间: 2016-10-31 17:40
日出而作，日落而写作。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)