测试计划总是受到项目计划影响而延期怎么办？（09-07-13）（获奖名单已公布）

默默巫

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

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



相关文章：

项目开发计划

如何编制成功的测试计划

更多内容请点击＞＞＞

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

fjstc3441

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

msnshow

如果只是跟进一个项目那还好，要是有很多的项目，某个项目的计划变了，影响了测试计划，接着就会影响别的项目的测试计划

zajy

观望，忠实的观众

xinwuhanqqm

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

helina168

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

1019

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

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

兰兰

阿七是做什么测试的，看了几个帖子都分析的很透彻呀

leafgemini

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

wangjingying

以下是小弟的一些看法，大虾们轻拍

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


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

woza

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

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

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

woza

不反对...

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

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

xiaonanzeng

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

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

阿七

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

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

不反对...

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

namisang

来瞧瞧大家的回答

yetties2005

走别人的路、叫别人无路可走

jsj1jsj

优化资源配置，合理安排项目进度，选对人再做事，防止项目之间相互影响

myklin

我也不知道怎么办，我来看看各位怎么办？

woza

瀑布对于需求变更没有任何抵抗力。

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

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

talent467

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

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

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