测试计划总是受到项目计划影响而延期怎么办？（09-07-13）（获奖名单已公布）
测试计划总是受到项目计划影响而延期怎么办？如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
相关文章：
项目开发计划
如何编制成功的测试计划
更多内容请点击＞＞＞
获奖名单奖项获奖名单奖励答案链接一等奖woodcraft当当购物卡50元2# 从我们团队的经验来看：项目计划变化一般分为需求变化、资源变化、进度变化3种。
1、需求变化。这是最没有办法的。除了重新定义测试计划外，似乎没什么可做的了。
在这种变化中，我认为最重要的测试主管的坚持，需要对需求重新分析，并要求足够的资源与进度。
2、资源变化。经常出现的情况是资源被其他项目挪用或者临时异常。
目前的措施是做好测试主管的备份，任何项目都安排1个2人小组负责，当然，测试主管只有1个。
在资源被其他项目挪用时，我要求任何项目都不能停止，至少由测试主管以天为单位跟踪项目进度，直到项目真正CLOSE。
3、进度变化。这就需要看测试团队负责人与测试负责人的沟通能力了。
如果进度要求提前时，如果测试主管无法改变（一般也无法改变），一定要做好风险管理与预警。
变化总比计划快，我认为应对的措施只有两条：
1、进度管理与实时分析。不要让测试进度失去控制。在任何时候都要知道目前测试所处的阶段，并针对目前的情况实时分析，考虑在现有情况下的下一步计划。不要等，等需求、等开发，多考虑现在我们能做什么？
2、风险管理。作为测试负责人，在了解目前测试所处的阶段的情况下，还需要实时跟踪目前的项目风险。当临时遇到发布要求时，能尽可能的提供目前的风险，作为与项目经理沟通的依据。并在无法改变发布要求时能提前做好风险应对措施。
测试计划要服从项目计划
观点：软件测试是项目的一个部分，测试计划必须服从项目计划，根据项目计划的变化而发生相应的变化。首先，具体如何变需要测试负责人（测试主管或者组长）根据项目的实际情况把握，时刻以Bug为中心，再开始测试前我们是为更多的发现bug做准备，那么在必须牺牲一些环节的时候要考虑希望哪些环节对bug的发现影响最小。
其次，如果测试经理是个完美的过程主意者，当项目计划变化引起测试进度可能延期时，他也不想牺牲任何测试环节，要求每个环节都要踏踏实实做好的话。为了保证进度只有一个办法：增加资源（人力资源、测试工具等等）。
最后，如果所在的公司没有质量保证部门，那么测试人员就要充当两个角色，在项目工期非常紧张的情况下，要定期将测试工作尤其是测试结果报告给具有决策权的上级（如，项目经理或者高管），在明确的测试结果面前我想上级会权衡利弊，统筹全局作出最好的决策。
最简单的做发-制定优先级
简单的做法：把所有需要测试的内容排优先级。然后告诉相关人等，如果只有一天时间，能做什么测试；如果有一周，一月，能做什么测试。同时告诉大家各种做法的风险。当然，作为管理者还有很多沟通协调的事情要做。
小七 我回归啦!!!!!!!!
测试计划总是受到项目计划影响而延期怎么办？这个问题比较普遍,国内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 编辑 ] 2楼和3楼回答的都非常的好，什么是测试，我记得有一次参加51举办的沙龙，有个朋友说的特别好。测试其实就是在寻找成本和质量的一个平衡点。 凉拌...:hug: 原帖由 阿七 于 2009-7-15 11:51 发表 http://bbs.51testing.com/images/common/back.gif
凉拌...:hug:
::xsjsn:::你..
大家都来参与讨论吧!::zhuhe:::
回复 5# 的帖子
瀑布模式下，项目延期无可避免。建议使用敏捷模式。至少在关键阶段使用敏捷方法。比如说在做项目计划的时候，让工程师自己去估计工作量。这样比项目经理估计的要准很多。
再比如，把测试通过作为任务完成的标准之一，并且把开发测试人员捆绑在一起。这样可以避免测试时间被压缩的问题。
还有减少会议，减少不必要的文档，减少管理人员的不必要干预也可以节约很多项目时间。
我们现在做项目，基本上没有延期发生。测试时间的问题也比较少。 项目延期主要还是需求变换太频繁 引起的 一般情况下 不太会延期 呵呵 首先，项目计划的调整是不可避免的。测试计划随项目计划进行调整也就是必然的了。
可以先对调整原因进行分析
如果是日程delay，作为QA来说可以对抽取的内容进行调整，如果是必须检查的模块，可以考虑与项目的UT同步进行。那么对于发现的缺陷，可能会出现同件很多的现象，这应该是正常的。
如果是全查，测试与项目共同进退也就得面对现实了。项目组都在加班的时候，测试轻松也是不太可能的事情哦。
那如果是需求变更的话，看使用什么生命周期了。如果一开始就知道会有很多变化的话，就不要选择瀑布模型啦。如果已经选择了瀑布模型，我觉得项目经理会比测试人员更头痛吧。其实主要看项目进行到什么阶段。如果还没有进入基线，可能还好办，如果已经进入基线，应该按照组织规定进行变更手续加以控制，以避免漏对应和对应影响范围失控。
[ 本帖最后由 talent467 于 2009-7-15 17:55 编辑 ]
回复 10# 的帖子
瀑布对于需求变更没有任何抵抗力。使用敏捷的话，需求变更基本上没有影响。敏捷欢迎需求变更。我们做软件的目的不是为了把计划好的东西做出来，而是为用户解决问题。如果用户变更需求，说明他们对于我们在做的事情有反馈，反馈越多有用的信息也就越多。这样做出来的东西才更加符合客户的实际需要。
[ 本帖最后由 woza 于 2009-7-16 09:08 编辑 ] 我也不知道怎么办，我来看看各位怎么办？:loveliness: 优化资源配置，合理安排项目进度，选对人再做事，防止项目之间相互影响 走别人的路、叫别人无路可走:lol 来瞧瞧大家的回答:lol 原帖由 woza 于 2009-7-16 09:03 发表 http://bbs.51testing.com/images/common/back.gif
瀑布对于需求变更没有任何抵抗力。
使用敏捷的话，需求变更基本上没有影响。敏捷欢迎需求变更。我们做软件的目的不是为了把计划好的东西做出来，而是为用户解决问题。如果用户变更需求，说明他们对于我们在做的事 ...
不反对...
要补充... 需求变更 无论是瀑布 还是敏捷 对于多出来的工作量 总是要去消化的呀 需要变更对整个项目都会有影响，更改计划属于正常情况，如果变更以后明显的增加了工作量，计划不改还能按计划完成，这才是问题了。所以我们应该讨论的是没变更的情况下，因开发的进度而影响测试的计划，在这种情况下我们如何应对：
1、开发延迟了进度，测试进度也对应往后延，没问题。大多数情况项目经理会决定，开发延了测试不延，这就涉及到测试人员的重视性问题，很敏感，做为测试责任人必须力争。
2、开发和测试为什么要分成两个部门？部门与部门之间应该是相互约束的，如果测试人员遇到这种情况，一味的为解决问题而服从，对于组织来说就是恶性循环。所以必须找出开发进度滞后的原因，并且给想办法给开发施加压力。有压力才有动力，唉！人就这样。
3、瀑布式的核心在于每个环节的进出口条件，不是以人为本。我热忠于这种模式，不受人员因素所左右，不象敏捷模式，以人为本。
仔细想想涉及的东东太多了，个人意见还请各位指正。
不反对...
要补充... 需求变更 无论是瀑布 还是敏捷 对于多出来的工作量 总是要去消化的呀
敏捷的迭代周期是固定的。在开发过程中每个需求都有优先级。开发团队始终先在固定周期内完成优先级高的需求。因此一旦用户增加新的需求，就意味着低优先级的需求从这个周期里面被拿掉了。所以工作量基本是持平的。 原帖由 xiaonanzeng 于 2009-7-16 17:51 发表 http://bbs.51testing.com/images/common/back.gif
需要变更对整个项目都会有影响，更改计划属于正常情况，如果变更以后明显的增加了工作量，计划不改还能按计划完成，这才是问题了。所以我们应该讨论的是没变更的情况下，因开发的进度而影响测试的计划，在这种情况下 ...
如果需求不发生变化，那用什么模式都问题不大。事实上这种情况很少发生。多数情况是需求变更太多，导致开发无法按时完成，所以牛人们才千方百计寻找可以因对各种情况的模型。
就我的经验而言，开发和测试对立对于开发过程没有任何帮助。合作才是利人利己的解决办法。当一个团队为了共同目标奋斗的时候，爆发出的力量是完全不可想象的。而开发和测试人员的最终目标其实是完全一致的。与其依靠测试人员给开发人员压力，不如把质量的目标变成整个团队的目标。这样开发人员就会主动配合测试工作。
页:
[1]
2
