51Testing软件测试论坛

标题: 测试计划总是受到项目计划影响而延期怎么办？（09-07-13）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-7-13 14:31
标题: 测试计划总是受到项目计划影响而延期怎么办？（09-07-13）（获奖名单已公布）
测试计划总是受到项目计划影响而延期怎么办？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

相关文章：

项目开发计划

如何编制成功的测试计划

更多内容请点击＞＞＞

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	woodcraft	当当购物卡50元	2#

作者: woodcraft 时间: 2009-7-13 18:53
从我们团队的经验来看：项目计划变化一般分为需求变化、资源变化、进度变化3种。

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

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

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

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

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

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

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

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

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

2、风险管理。作为测试负责人，在了解目前测试所处的阶段的情况下，还需要实时跟踪目前的项目风险。当临时遇到发布要求时，能尽可能的提供目前的风险，作为与项目经理沟通的依据。并在无法改变发布要求时能提前做好风险应对措施。

作者: dqar 时间: 2009-7-14 13:21
标题: 测试计划要服从项目计划
观点：软件测试是项目的一个部分，测试计划必须服从项目计划，根据项目计划的变化而发生相应的变化。

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

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

最后，如果所在的公司没有质量保证部门，那么测试人员就要充当两个角色，在项目工期非常紧张的情况下，要定期将测试工作尤其是测试结果报告给具有决策权的上级（如，项目经理或者高管），在明确的测试结果面前我想上级会权衡利弊，统筹全局作出最好的决策。

作者: woza 时间: 2009-7-14 14:03
标题: 最简单的做发-制定优先级
简单的做法：把所有需要测试的内容排优先级。然后告诉相关人等，如果只有一天时间，能做什么测试；如果有一周，一月，能做什么测试。同时告诉大家各种做法的风险。

当然，作为管理者还有很多沟通协调的事情要做。

作者: 阿七 时间: 2009-7-14 18:38
标题: 小七我回归啦!!!!!!!!
测试计划总是受到项目计划影响而延期怎么办？

这个问题比较普遍,国内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 时间: 2009-7-14 18:47
2楼和3楼回答的都非常的好，什么是测试，我记得有一次参加51举办的沙龙，有个朋友说的特别好。测试其实就是在寻找成本和质量的一个平衡点。

作者: 阿七 时间: 2009-7-15 11:51
凉拌...

作者: 默默巫 时间: 2009-7-15 12:26

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

::xsjsn::: 你..

大家都来参与讨论吧!::zhuhe:::

作者: woza 时间: 2009-7-15 14:43
标题: 回复 5# 的帖子
瀑布模式下，项目延期无可避免。建议使用敏捷模式。至少在关键阶段使用敏捷方法。

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

我们现在做项目，基本上没有延期发生。测试时间的问题也比较少。

作者: 阿七 时间: 2009-7-15 16:58
项目延期主要还是需求变换太频繁引起的一般情况下不太会延期呵呵

作者: talent467 时间: 2009-7-15 17:53
首先，项目计划的调整是不可避免的。测试计划随项目计划进行调整也就是必然的了。
可以先对调整原因进行分析
如果是日程delay，作为QA来说可以对抽取的内容进行调整，如果是必须检查的模块，可以考虑与项目的UT同步进行。那么对于发现的缺陷，可能会出现同件很多的现象，这应该是正常的。
如果是全查，测试与项目共同进退也就得面对现实了。项目组都在加班的时候，测试轻松也是不太可能的事情哦。

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

[ 本帖最后由 talent467 于 2009-7-15 17:55 编辑 ]

作者: woza 时间: 2009-7-16 09:03
标题: 回复 10# 的帖子
瀑布对于需求变更没有任何抵抗力。

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

[ 本帖最后由 woza 于 2009-7-16 09:08 编辑 ]

作者: myklin 时间: 2009-7-16 09:51
我也不知道怎么办，我来看看各位怎么办？

作者: jsj1jsj 时间: 2009-7-16 14:47
优化资源配置，合理安排项目进度，选对人再做事，防止项目之间相互影响

作者: yetties2005 时间: 2009-7-16 15:52
走别人的路、叫别人无路可走

作者: namisang 时间: 2009-7-16 16:51
来瞧瞧大家的回答

作者: 阿七 时间: 2009-7-16 17:16

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

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

不反对...

要补充... 需求变更无论是瀑布还是敏捷对于多出来的工作量总是要去消化的呀

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

仔细想想涉及的东东太多了，个人意见还请各位指正。

作者: woza 时间: 2009-7-17 08:39

不反对...

要补充... 需求变更无论是瀑布还是敏捷对于多出来的工作量总是要去消化的呀

敏捷的迭代周期是固定的。在开发过程中每个需求都有优先级。开发团队始终先在固定周期内完成优先级高的需求。因此一旦用户增加新的需求，就意味着低优先级的需求从这个周期里面被拿掉了。所以工作量基本是持平的。

作者: woza 时间: 2009-7-17 08:53

原帖由 xiaonanzeng 于 2009-7-16 17:51 发表
需要变更对整个项目都会有影响，更改计划属于正常情况，如果变更以后明显的增加了工作量，计划不改还能按计划完成，这才是问题了。所以我们应该讨论的是没变更的情况下，因开发的进度而影响测试的计划，在这种情况下 ...

如果需求不发生变化，那用什么模式都问题不大。事实上这种情况很少发生。多数情况是需求变更太多，导致开发无法按时完成，所以牛人们才千方百计寻找可以因对各种情况的模型。

就我的经验而言，开发和测试对立对于开发过程没有任何帮助。合作才是利人利己的解决办法。当一个团队为了共同目标奋斗的时候，爆发出的力量是完全不可想象的。而开发和测试人员的最终目标其实是完全一致的。与其依靠测试人员给开发人员压力，不如把质量的目标变成整个团队的目标。这样开发人员就会主动配合测试工作。

作者: wangjingying 时间: 2009-7-17 15:43
以下是小弟的一些看法，大虾们轻拍

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

项目中有哪些主要因素会导致测试计划延期以及怎么办？
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. 接受现实，延期、延长测试

作者: leafgemini 时间: 2009-7-20 15:20
瀑布在安排项目的开始到发布上就存在问题，它把测试环节放在后面~~那就无法排除需求中存在的很多设计上的BUG。如果吧这些BUG保留到编码实现阶段的话，项目延期时必然的结果。而其会耗费更多的人力和财力... ...

作者: 兰兰 时间: 2009-7-23 10:22
阿七是做什么测试的，看了几个帖子都分析的很透彻呀

作者: 1019 时间: 2009-7-29 11:14
这个问题也困扰我了许久了，今天来学习下，同时也谈谈自己的经历吧。
做测试部经理一年多了，也经历了多个项目，每一个项目的计划从来都没有按时完成过，需求变化那简直就是一天一变，而且变的是面目全非。
开发基本上没有需求文档，就算有，开发一段时间后，实际开发出的东西已与文档完全不一样了，所以说哪怕我们事先了解了需求，但是到测试的时候仍然是空白。
另外，抽个时间组织开个一天两天的会议（需要研发总监参与确认），把界面过一道，然后又整理一大堆的问题修改，你说这样的情况怎么可能不拖延计划，测试呢好不容易测的差不多了，结果又要重新测试。
我现在的做法就是，开发提交就赶紧测试功能，在测试的过程中整理界面上的问题和设计本身存在的逻辑问题，然后提交开发经理取舍修改需要改的问题，以前是提交研发总监（总监说改就改，但是慢慢的发现，他太忙了，并且没有真正的参与到项目中，有很多东西看的都不太透彻），哎，导致测试总跟着开发的后头，完成不了就加班加班，到最后总监发现哪个不符合他要求的，那就是测试的责任了，进度也是测试没有控制好，反正开发好像没有什么问题。有功劳的时候就是他们，头痛呀。

[ 本帖最后由 1019 于 2009-7-29 11:21 编辑 ]

作者: helina168 时间: 2009-8-17 19:30
楼上的说到我的苦处了，我们公司的需求也差不多是一天天变，或者说根本就没有需求，就算有，做出来的功能也不完全符合需求，感觉需求就是一个形式而已，在此学习了！我们公司好像从没按项目计划来进行过，都是做到哪算到哪，计划只是给领导看的

作者: xinwuhanqqm 时间: 2009-8-24 16:29
如果没有很好的规范来明确开发、测试之间这种难于区分的责任关系，确实测试人员会吃亏。建议开发方、测试方、领导三方都意识到项目实施中这种普遍存在的难题，然后共同商定一个简单的流程或约定，规范开发到测试的操作。

作者: zajy 时间: 2009-9-4 15:39
观望，忠实的观众

作者: msnshow 时间: 2010-4-26 13:51
如果只是跟进一个项目那还好，要是有很多的项目，某个项目的计划变了，影响了测试计划，接着就会影响别的项目的测试计划

作者: fjstc3441 时间: 2010-6-25 15:20
其实一般IT行业中，最为痛苦的是研发日程Delay，而发布时间不变的这个情况。直接导致原定测试时间缩短，影响测试工作以及产品质量。
现在我作为QA经理，也一直很头疼这个问题，现在我们的做法是通过敏捷开发的形式，将问题尽早的发现，但是问题只是解决了一点而已。
关键还是质量意识的推广上来解决根本问题，如果整个项目都能够按照"零缺陷"的观念去开发的话，这种延期的事项会非常的少。即使有，也能够迎刃而解。

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