我觉得测试计划是项目计划的一部分，所以测试计划是否受到项目的影响而延期不是关键问题，关键在于测试计划（受到项目影响）的延期是否会导致项目的延期或者其他一些不利的后果(成本上升等)。还有我们如何从测试层面去预防、解决或者减少这些对项目不利的影响？
项目中有哪些主要因素会导致测试计划延期以及怎么办？
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. 接受现实，延期、延长测试 瀑布在安排项目的开始到发布上就存在问题，它把测试环节放在后面~~那就无法排除需求中存在的很多设计上的BUG。如果吧这些BUG保留到编码实现阶段的话，项目延期时必然的结果。而其会耗费更多的人力和财力... ... 阿七是做什么测试的，看了几个帖子都分析的很透彻呀 这个问题也困扰我了许久了，今天来学习下，同时也谈谈自己的经历吧。
做测试部经理一年多了，也经历了多个项目，每一个项目的计划从来都没有按时完成过，需求变化那简直就是一天一变，而且变的是面目全非。
开发基本上没有需求文档，就算有，开发一段时间后，实际开发出的东西已与文档完全不一样了，所以说哪怕我们事先了解了需求，但是到测试的时候仍然是空白。
另外，抽个时间组织开个一天两天的会议（需要研发总监参与确认），把界面过一道，然后又整理一大堆的问题修改，你说这样的情况怎么可能不拖延计划，测试呢好不容易测的差不多了，结果又要重新测试。
我现在的做法就是，开发提交就赶紧测试功能，在测试的过程中整理界面上的问题和设计本身存在的逻辑问题，然后提交开发经理取舍修改需要改的问题，以前是提交研发总监（总监说改就改，但是慢慢的发现，他太忙了，并且没有真正的参与到项目中，有很多东西看的都不太透彻），哎，导致测试总跟着开发的后头，完成不了就加班加班，到最后总监发现哪个不符合他要求的，那就是测试的责任了，进度也是测试没有控制好，反正开发好像没有什么问题。有功劳的时候就是他们，头痛呀。
[ 本帖最后由 1019 于 2009-7-29 11:21 编辑 ] 楼上的说到我的苦处了，我们公司的需求也差不多是一天天变，或者说根本就没有需求，就算有，做出来的功能也不完全符合需求，感觉需求就是一个形式而已，在此学习了！我们公司好像从没按项目计划来进行过，都是做到哪算到哪，计划只是给领导看的:( 如果没有很好的规范来明确开发、测试之间这种难于区分的责任关系，确实测试人员会吃亏。建议开发方、测试方、领导三方都意识到项目实施中这种普遍存在的难题，然后共同商定一个简单的流程或约定，规范开发到测试的操作。 观望，忠实的观众 如果只是跟进一个项目那还好，要是有很多的项目，某个项目的计划变了，影响了测试计划，接着就会影响别的项目的测试计划 其实一般IT行业中，最为痛苦的是研发日程Delay，而发布时间不变的这个情况。直接导致原定测试时间缩短，影响测试工作以及产品质量。
现在我作为QA经理，也一直很头疼这个问题，现在我们的做法是通过敏捷开发的形式，将问题尽早的发现，但是问题只是解决了一点而已。
关键还是质量意识的推广上来解决根本问题，如果整个项目都能够按照"零缺陷"的观念去开发的话，这种延期的事项会非常的少。即使有，也能够迎刃而解。
页:
1
[2]
