如果需求一直在变化怎么办

这是一个常见的令人头疼的问题。

如果可能,尽早与承担该项目风险的人接触,以便了解需求会怎样改变,从而可以尽早地改变测试计划和策略。

如果在对应用程序进行初始设计时多考虑一些适应性,那么以后在发生需求的改变时,就不需要再为改变做很多事情了。

好的代码注释和好的文档有助于开发人员作出相应的改变。

只要有可能,就应使用快速原型 (rapid prototyping),以帮助用户确认他们的需求,从而减少变更。

在项目的时间表中应当留出余量,以应付可能出现的变更。

尽量把新的需求纳入应用软件的“下一版”,而把原始需求作为“第一版”。

通过谈判,把易于实现的新的变更列入项目,而把难于实现的新需求列入该应用软件的以后的版本。

要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

在应付改变时,应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

在设计自动测试剧本时,试图使其有一些灵活性。

在对应用软件进行自动测试时,要把注意力集中在看来不大会改变的部分。

对变更进行适当的风险分析,以减少回归测试的要求。

在设计测试案例时要有一定的灵活性。做到这一点并不容易,所以要降低测试案例的详细程度,或者只建立高级的通用型的测试计划。

少注意详细的测试计划和测试案例,要把重点放在专门的测试 (ad hoc testing) 上。

这是一个常见的令人头疼的问题。

如果可能,尽早与承担该项目风险的人接触,以便了解需求会怎样改变,从而可以尽早地改变测试计划和策略。

如果在对应用程序进行初始设计时多考虑一些适应性,那么以后在发生需求的改变时,就不需要再为改变做很多事情了。

好的代码注释和好的文档有助于开发人员作出相应的改变。

只要有可能,就应使用快速原型 (rapid prototyping),以帮助用户确认他们的需求,从而减少变更。

在项目的时间表中应当留出余量,以应付可能出现的变更。

尽量把新的需求纳入应用软件的“下一版”,而把原始需求作为“第一版”。

通过谈判,把易于实现的新的变更列入项目,而把难于实现的新需求列入该应用软件的以后的版本。

要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

在应付改变时,应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

在设计自动测试剧本时,试图使其有一些灵活性。

在对应用软件进行自动测试时,要把注意力集中在看来不大会改变的部分。

对变更进行适当的风险分析,以减少回归测试的要求。

在设计测试案例时要有一定的灵活性。做到这一点并不容易,所以要降低测试案例的详细程度,或者只建立高级的通用型的测试计划。

少注意详细的测试计划和测试案例,要把重点放在专门的测试 (ad hoc testing) 上。