谁都是自己问题的答案

测试计划总是受到项目计划影响而延期怎么办?

上一篇 / 下一篇  2009-07-13 16:25:54 / 个人分类:论坛活动

查看( 1689 ) / 评论( 28 )

测试计划总是受到项目计划影响而延期怎么办?

点击参与:http://bbs.51testing.com/thread-159042-1-1.html



 


TAG:

测测停停 woodcraft 发布于2009-07-13 18:53:37
从我们团队的经验来看:项目计划变化一般分为需求变化、资源变化、进度变化3种。

1、需求变化。这是最没有办法的。除了重新定义测试计划外,似乎没什么可做的了。

在这种变化中,我认为最重要的测试主管的坚持,需要对需求重新分析,并要求足够的资源与进度。

2、资源变化。经常出现的情况是资源被其他项目挪用或者临时异常。

目前的措施是做好测试主管的备份,任何项目都安排1个2人小组负责,当然,测试主管只有1个。

在资源被其他项目挪用时,我要求任何项目都不能停止,至少由测试主管以天为单位跟踪项目进度,直到项目真正CLOSE。

3、进度变化。这就需要看测试团队负责人与测试负责人的沟通能力了。

如果进度要求提前时,如果测试主管无法改变(一般也无法改变),一定要做好风险管理与预警。


变化总比计划快,我认为应对的措施只有两条:

1、进度管理与实时分析。不要让测试进度失去控制。在任何时候都要知道目前测试所处的阶段,并针对目前的情况实时分析,考虑在现有情况下的下一步计划。不要等,等需求、等开发,多考虑现在我们能做什么?

2、风险管理。作为测试负责人,在了解目前测试所处的阶段的情况下,还需要实时跟踪目前的项目风险。当临时遇到发布要求时,能尽可能的提供目前的风险,作为与项目经理沟通的依据。并在无法改变发布要求时能提前做好风险应对措施。
测试很容易,做好非常难 dqar 发布于2009-07-14 13:21:27
测试计划要服从项目计划
观点:软件测试是项目的一个部分,测试计划必须服从项目计划,根据项目计划的变化而发生相应的变化。

首先,具体如何变需要测试负责人(测试主管或者组长)根据项目的实际情况把握,时刻以Bug为中心,再开始测试前我们是为更多的发现bug做准备,那么在必须牺牲一些环节的时候要考虑希望哪些环节对bug的发现影响最小。

其次,如果测试经理是个完美的过程主意者,当项目计划变化引起测试进度可能延期时,他也不想牺牲任何测试环节,要求每个环节都要踏踏实实做好的话。为了保证进度只有一个办法:增加资源(人力资源、测试工具等等)。

最后,如果所在的公司没有质量保证部门,那么测试人员就要充当两个角色,在项目工期非常紧张的情况下,要定期将测试工作尤其是测试结果报告给具有决策权的上级(如,项目经理或者高管),在明确的测试结果面前我想上级会权衡利弊,统筹全局作出最好的决策。
Darren Li 的个人空间 woza 发布于2009-07-14 14:03:14
最简单的做发-制定优先级
简单的做法:把所有需要测试的内容排优先级。然后告诉相关人等,如果只有一天时间,能做什么测试;如果有一周,一月,能做什么测试。同时告诉大家各种做法的风险。

当然,作为管理者还有很多沟通协调的事情要做。
无以伦比 阿七 发布于2009-07-14 18:38:10
小七 我回归啦!!!!!!!!
测试计划总是受到项目计划影响而延期怎么办?

这个问题比较普遍,国内90%的IT项目延期实施,50%的IT项目超出预算,50%的IT项目无法达到预定目标。自己也遇到过多次的项目延期,这里来说下自己的看法.

首先我要说下整个项目的构成
启动—计划—评审—设计—开发—测试—发布,总结
测试是项目的最后一环,测试计划总是会受到项目影响而变化,但是测试计划是项目计划的一部分.所以测试计划需要项目计划的支持,同时对一些无法改变的事做出应对.

1 合理编制项目进度计划
项目进度计划的编制,看起来似乎是件容易的事,但其实要对项目的各个环节、工作内容与工作量都要有深入了解,是一项很重要的工作。如何将计划编制得既有指导性,又有可操作性,还要有合理性,不是件容易的事。很多时候,项目计划的编制是由项目经理一个人独立编制的或者是例会大概估算的。这种计划本身便有其不合理性。一个人不可能对各个业务部门的情况都了如指掌,所以他认为简单的事,其实会有很大的工作量。
我认为,一个理想的项目进度计划应该是可以得到随时调整但是并不影响项目最终的结束时间。因此,计划的制定,应该充分利用起各个部门负责人的经验资源,先由他们各自准备一份自己部门内的工作计划,然后集中交由项目经理,综合评估。这样的计划编制出来,才是一个可行的计划.测试是计划的最后一环,目前的现状是:为了项目发布,需要压缩测试时间,或者要放弃一部分功能,或者加班赶来弥补其他的计划延时.这样的话定计划的时候,就需要预想到,这样测试计划才不会因为计划变化而做巨大调整.

2、相应的控制措施以保证计划的实施
测试计划是根据项目计划变化而变化的,这点事无法改变的.源头不堵,到了我们测试的后头,影响力是不大的,伴随的就是 加班 加班 上面改需求, 我们改用列 ,很被动.
所以项目计划必须要得到各部门负责人的大力支持,要让他们明确项目实施后对其部门所带来的益处,要让他们由被动接受的态度转向主动积极的配合。另外,可以制定一些奖惩制度,奖励是主要,惩罚是辅助手段,调动起所有人员的积极性来,相信可以做得更好。

3、优秀的项目经理和有序的项目管理
要很好地完成项目,必须要有一个优秀的项目经理,进行有序的项目管理才能够实现。项目经理的人选不单要具备专业的技术知识,还要有丰富的管理能力,要有分析并解决问题的能力。抓住项目实施过程中的一些关键节点,密切注意进展情况,一旦出现问题,应该马上拿出切实可行的措施。建立完善的问题管理程序,定期举行会议。另外,在项目实施的过程中,多多少少都会发生一些范围变更,项目经验一定要严格控制这些变更,对这些变更有一个应对方案,综合平衡分析变更的必须性,把变更范围控制在可控范围内,不然便会出现很多并发症,由此引起进度方面的调整、费用增加等,导致项目在进度和经济利益上受到损失。


下面说说对于那些我们测试无法改变的事,要做那些应对?

4、克服“完美主义”倾向
每个项目实施,都存在一个问题,就是寻找成本和质量的一个平衡点。有时候时间紧,需要马上发布占领市场,但是又担心发布后存在问题,造成坏的影响.那么我们的测试计划也要考虑到这点,如果项目延迟了,需要对项目进行筛选,不能存在大的BUG ,小的BUG 则可以放过,等bate版本在进行修补,克服”完美主义”的思想.

5、压缩测试流程
项目计划的变化,导致测试计划的变化,这无法改变,那么为了保证优先的项目,则可以适当的压缩测试流程,如需求发生变化,那么测试用列要变化,然后可能会需要评审等,那么可以在需求确定要变化的时候,需求,开发,测试人员到一起讨论, 得到答案后,直接应用于测试,跳过书面的东西.

6、准备测试数据,多用软件
建立测试数据库,如一些自动化测试用列,一些可以套用的测试用列和稍微改改就能用的则用机器去跑了,这样可以减少测试人员的工作量.空出时间应对项目延时的东东.
没有测试库的,可以在test环境下开始准备,等test 的第2,3轮—deploy模拟-发布确认就都可以使用,减少工作量.

7、物理办法
加班—加班—持续加班!!!这样可以弥补下进度和项目的延时.(目前最普遍最常用的办法) 鄙视之…

阿七签名专用… 嘿嘿




Ps:另外还需要说下的是,这次的项目延期了,基本上做的措施很难发挥立竿见影的效果,积极意义是能通过这次的事件,看见那个环节出了问题,避免下次再发生这样的情况.所以项目后的总结是很重要的.







[ 本帖最后由 阿七 于 2009-7-15 11:48 编辑 ]
peterz的个人空间 peterz 发布于2009-07-14 18:47:51
2楼和3楼回答的都非常的好,什么是测试,我记得有一次参加51举办的沙龙,有个朋友说的特别好。测试其实就是在寻找成本和质量的一个平衡点。
无以伦比 阿七 发布于2009-07-15 11:51:19
凉拌...
魔女宅 默默巫 发布于2009-07-15 12:26:53

QUOTE:

原帖由 阿七 于 2009-7-15 11:51 发表
凉拌...
  你..

大家都来参与讨论吧!
Darren Li 的个人空间 woza 发布于2009-07-15 14:43:21
回复 5# 的帖子
瀑布模式下,项目延期无可避免。建议使用敏捷模式。至少在关键阶段使用敏捷方法。

比如说在做项目计划的时候,让工程师自己去估计工作量。这样比项目经理估计的要准很多。
再比如,把测试通过作为任务完成的标准之一,并且把开发测试人员捆绑在一起。这样可以避免测试时间被压缩的问题。
还有减少会议,减少不必要的文档,减少管理人员的不必要干预也可以节约很多项目时间。

我们现在做项目,基本上没有延期发生。测试时间的问题也比较少。
无以伦比 阿七 发布于2009-07-15 16:58:58
项目延期  主要还是需求变换太频繁 引起的    一般情况下 不太会延期   呵呵
talent467发布于2009-07-15 17:53:07
首先,项目计划的调整是不可避免的。测试计划随项目计划进行调整也就是必然的了。
可以先对调整原因进行分析
如果是日程delay,作为QA来说可以对抽取的内容进行调整,如果是必须检查的模块,可以考虑与项目的UT同步进行。那么对于发现的缺陷,可能会出现同件很多的现象,这应该是正常的。
如果是全查,测试与项目共同进退也就得面对现实了。项目组都在加班的时候,测试轻松也是不太可能的事情哦。

那如果是需求变更的话,看使用什么生命周期了。如果一开始就知道会有很多变化的话,就不要选择瀑布模型啦。如果已经选择了瀑布模型,我觉得项目经理会比测试人员更头痛吧。其实主要看项目进行到什么阶段。如果还没有进入基线,可能还好办,如果已经进入基线,应该按照组织规定进行变更手续加以控制,以避免漏对应和对应影响范围失控。

[ 本帖最后由 talent467 于 2009-7-15 17:55 编辑 ]
Darren Li 的个人空间 woza 发布于2009-07-16 09:03:21
回复 10# 的帖子
瀑布对于需求变更没有任何抵抗力。

使用敏捷的话,需求变更基本上没有影响。敏捷欢迎需求变更。我们做软件的目的不是为了把计划好的东西做出来,而是为用户解决问题。如果用户变更需求,说明他们对于我们在做的事情有反馈,反馈越多有用的信息也就越多。这样做出来的东西才更加符合客户的实际需要。

[ 本帖最后由 woza 于 2009-7-16 09:08 编辑 ]
卓别小林的个人空间 myklin 发布于2009-07-16 09:51:01
我也不知道怎么办,我来看看各位怎么办?
jsj1jsj的个人空间 jsj1jsj 发布于2009-07-16 14:47:09
优化资源配置,合理安排项目进度,选对人再做事,防止项目之间相互影响
yetties2005的个人空间 yetties2005 发布于2009-07-16 15:52:55
走别人的路、叫别人无路可走
namisang的个人空间 namisang 发布于2009-07-16 16:51:37
来瞧瞧大家的回答
无以伦比 阿七 发布于2009-07-16 17:16:03

QUOTE:

原帖由 woza 于 2009-7-16 09:03 发表
瀑布对于需求变更没有任何抵抗力。

使用敏捷的话,需求变更基本上没有影响。敏捷欢迎需求变更。我们做软件的目的不是为了把计划好的东西做出来,而是为用户解决问题。如果用户变更需求,说明他们对于我们在做的事 ...
不反对...

要补充...   需求变更 无论是瀑布 还是敏捷 对于多出来的工作量 总是要去消化的呀
xiaonanzeng发布于2009-07-16 17:51:40
需要变更对整个项目都会有影响,更改计划属于正常情况,如果变更以后明显的增加了工作量,计划不改还能按计划完成,这才是问题了。所以我们应该讨论的是没变更的情况下,因开发的进度而影响测试的计划,在这种情况下我们如何应对:
1、开发延迟了进度,测试进度也对应往后延,没问题。大多数情况项目经理会决定,开发延了测试不延,这就涉及到测试人员的重视性问题,很敏感,做为测试责任人必须力争。
2、开发和测试为什么要分成两个部门?部门与部门之间应该是相互约束的,如果测试人员遇到这种情况,一味的为解决问题而服从,对于组织来说就是恶性循环。所以必须找出开发进度滞后的原因,并且给想办法给开发施加压力。有压力才有动力,唉!人就这样。
3、瀑布式的核心在于每个环节的进出口条件,不是以人为本。我热忠于这种模式,不受人员因素所左右,不象敏捷模式,以人为本。

仔细想想涉及的东东太多了,个人意见还请各位指正。
Darren Li 的个人空间 woza 发布于2009-07-17 08:39:25

QUOTE:

不反对...

要补充...   需求变更 无论是瀑布 还是敏捷 对于多出来的工作量 总是要去消化的呀
敏捷的迭代周期是固定的。在开发过程中每个需求都有优先级。开发团队始终先在固定周期内完成优先级高的需求。因此一旦用户增加新的需求,就意味着低优先级的需求从这个周期里面被拿掉了。所以工作量基本是持平的。
Darren Li 的个人空间 woza 发布于2009-07-17 08:53:30

QUOTE:

原帖由 xiaonanzeng 于 2009-7-16 17:51 发表
需要变更对整个项目都会有影响,更改计划属于正常情况,如果变更以后明显的增加了工作量,计划不改还能按计划完成,这才是问题了。所以我们应该讨论的是没变更的情况下,因开发的进度而影响测试的计划,在这种情况下 ...
如果需求不发生变化,那用什么模式都问题不大。事实上这种情况很少发生。多数情况是需求变更太多,导致开发无法按时完成,所以牛人们才千方百计寻找可以因对各种情况的模型。

就我的经验而言,开发和测试对立对于开发过程没有任何帮助。合作才是利人利己的解决办法。当一个团队为了共同目标奋斗的时候,爆发出的力量是完全不可想象的。而开发和测试人员的最终目标其实是完全一致的。与其依靠测试人员给开发人员压力,不如把质量的目标变成整个团队的目标。这样开发人员就会主动配合测试工作。
wangjingying发布于2009-07-17 15:43:02
以下是小弟的一些看法,大虾们轻拍

我觉得测试计划是项目计划的一部分,所以测试计划是否受到项目的影响而延期不是关键问题,关键在于测试计划(受到项目影响)的延期是否会导致项目的延期或者其他一些不利的后果(成本上升等)。还有我们如何从测试层面去预防、解决或者减少这些对项目不利的影响?


项目中有哪些主要因素会导致测试计划延期以及怎么办?
1. 产品需求变更
2. 软件规格说明书变更
3. 开发计划延期
4. 资源变化

1. 产品需求变更
这是软件开发中一个非常甚至是极其普遍的想象。对于产品需求变更,我们需要重新分析、总结需求,修改或新建软件规格说明书,评估开发和测试的时间。对于由需求变更引起的测试延期,测试主管需要主动向项目相关人员以及项目主管汇报,说明测试延期的原因、具体时间以及可能对项目的影响,最后由项目经理决定是否接受或者去争取其他资源。个人觉得对于做项目的公司来说,既然是客户提出的需求变更,那么就大有和客户进行沟通并争取资源的机会。对于做产品的公司,可以根据需求变更的风险和市场预期来决定是否立即接受需求变更还是加入下一个版本。

2. 软件规格说明书变更
软件规格说明书变更的绝大多数原因是产品需求的变更,但是也有例外。比如开发在编码过程当中发现实现规格说明中的功能有很大困难或者测试人员发现规格说明书中的功能无法完全实现客户的需求。对于这个问题,我认为一定以预防为主。在软件规格说明书的编写过程中,需要软件规格设计人员、开发、测试的共同参与,力求从客户、软件架构、代码实现、测试评估等不同的视角去分析、讨论、总结和归纳。这样能尽早地发现问题、解决问题,最大程度预防和减少软件规格说明书变更造成的风险。

3. 开发计划的延期
开发计划延期的主要原因一般都是软件质量问题。对于这种情况,测试计划可以有选择
a. 测试计划相应延期
测试主管根据开发延期的具体情况、可调配资源、测试进展、项目进展总结归纳出测试延期的具体方案和对项目的影响,然后向项目相关人员以及项目主管报告。
b. 压缩测试计划
测试主管可以考虑减少测试迭代次数,缩短每次迭代周期,缩小测试覆盖面等方法。不过在考虑使用哪种方法前,软件质量风险是一个更重要的议题!

4. 资源变化
a. 硬件资源
如果是测试机器的问题,可以考虑利用虚拟机或者尽可能多地使用image来解决。如果是工具license的问题,可以考虑使用试用版工具来暂时缓解压力。
b. 人力资源
对于一家公司来说,人员流动是很正常的事情,所以在做测试计划时就应该把公司或者部门的人员年均流动率考虑进去,同时考虑新招人员的培训成本与培训时间。从另一个角度说,在安排测试计划的时候,每个测试模块或者说知识点至少要有两个人懂(可以只有1个人去做)。同时在测试进行当中,一定要按标准写好相关文档。这样的话,就不会因为人员的流动而造成知识当面的缺口了。
c. 项目预算
在金融危机的浪潮中, 项目的预算会或多或少地被削减,但是产品还是要高质量地交出去滴。对于这种大场面,我没有碰到过......


测试计划在哪个项目阶段受影响而延期以及怎么办?
RUP的主要项目阶段分为
1. 初始阶段
2. 细化阶段
3. 构造阶段
4. 交付阶段

1. 初始阶段
这个阶段和测试关系不大,忽略!

2. 细化阶段
细化阶段的主要工作是组织项目架构、编制项目计划(包括测试计划)。此阶段遇到的问题有产品需求变更、软件规格说明书变更、测试部门与其他部门之间的接口变更。在这个阶段出现的测试计划延期或者变化并不一定是坏事。问题越早暴露,那留给我们解决问题的时间就越多,供我们选择的方法也越多,回旋的余地也越大。对于这个时期测试计划的变化,我觉得测试主管只需要跟个部门沟通好就行了。

3. 构造阶段
在构造阶段,绝大部分的需求以及功能点都应该由开发完全,而且所有被开发的和已经存在的功能都必须被进行全面完整的测试。从我的经验来看,在这个阶段发生测试计划延期的频率最大而且影响也最严重。对于这个阶段的产品需求或软件规格说明书的变更,测试主管需要仔细考虑以下问题
a. 生产力(Capacity)
b. 持续时间(Duration)
c. 硬件资源
d. 知识储备
e. 人力资源、硬件资源、知识储备的耦合(这点似乎比较容易被忽视)
f. 测试与其他部门的接口
g. 软件质量风险
h. 项目风险后收益比
我觉得当以上几点被考虑与分析并且找到答案之后,那么对产品需求或规格说明书的变更是接受、拒绝还是找个折中的办法就比较明确了。

4. 交付阶段
在交付阶段之前,产品的功能、性能、兼容性等主要结构应该已经通过了比较全面的测试。因此这个阶段的重点是确保软件对终端用户是可用的,主要任务是通过用户的反馈,对软件进行调整、设置,解决安装、可用性和其他一些客户导向的问题。这个阶段会导致测试计划延期的因素主要是来自客户的反馈(如果客户发现的问题或者觉得不满意的地方太多就非常麻烦)。我个人习惯的做法有三种:
a. 解答客户的疑惑、问题,为客户找出简单易用的work around(这样可以降低问题的紧急性,研发的相关工作就可以推后了)
b. 加班加点(客户是上帝,只要客户的需求是紧急的,就要尽快地满足)
c. 接受现实,延期、延长测试
我来说两句

(可选)

Open Toolbar