电话:400-611-0571,0571-28180098
您的位置: 微软IT学院 >> 新闻资讯 >> 行业信息2 >> 面对需求变更,如何拥抱变化

面对需求变更,如何拥抱变化

  • 文章来源:微软IT学院
  • 浏览次数:
  • 发布时间:2013-12-24 15:53:42
文章摘要:清晰得记得,2007年的测试组例会,我们讨论的最多的问题就是,需求变更太多,导致我们测试工作量增多,产品发布日期一再拖延。  花费时间编写了详细的测试用例,可是突然重要功能需求变更了,那么需要重新修改;  构造好了测试数据,可是计算规则发。
清晰得记得,2007年的测试组例会,我们讨论的最多的问题就是,需求变更太多,导致我们测试工作量增多,产品发布日期一再拖延。

  花费时间编写了详细的测试用例,可是突然重要功能需求变更了,那么需要重新修改;

  构造好了测试数据,可是计算规则发生了变更,整个数据有需要重新来设计构造;

  临近产品发布了,需求变更,加入了影响重要的功能,导致产品稳定性变差,需要全部回归测试;

  ......

  导致了无休止的加班,发布日期不断的延迟。

  后来我们项目组开始敏捷,测试组也提倡“拥抱需求的变更,更主动地去参与变更”。测试组的具体措施是:用例简化、程序员按照测试要点开发功能、自动回归测试、积极沟通等。取得了一定的效果。

  现在,我们的项目开发团队在印度,测试团队在我们公司。怎么处理这样的问题:

  花了一个星期理解了需求、完成了用例、构造了测试数据。这时候,那边过来新版本需求文档,更改了计算规则,那么需求需要重新理解、用例和数据需要重新构造。这就需要大量的时间。这种问题以前常出现,以后还会常出现,我们如何解决。

  用例:开发编码的时期,我们工作量的最好体现就是测试用例,可是如果简化了用例,如何来体现我们的工作量。

  测试数据:版本发布后,我们的测试时间就会很紧张,所以要提前构建好大量的测试数据,等待版本发布测试更快些。可是这些构造好的测试数据一旦面临变更,那么维护起来也甚是麻烦。

  如果让程序员按照测试要点来开发功能,那么我们测试人员对于需求的掌握要不低于程序员,可是目前还是比较难实现,因为我们的需求相关问题全是从程序员哪里获取的。除非我们可以直接面对客户,而且还要有深厚的业务背景知识。

  那么我想可以从以下几个方面着手解决:

  ● 测试数据构造,减少手动操作,尽量自动构造;

  ● 用例编写,每个用例都沟通明确,且记录变更,准确计算需求变更导致的用例维护时间,可以分清责任;

  ● 提高自动测试程度,由于需求变更,需要进行的大量回归测试自动执行,节约时间和人力;

  ● 沟通:不怕麻烦,确认细节,减少理解误差造成的问题。

  ● ......

  当然光靠上面几点可能不是很好解决问题的,刚参与这个项目,需要了解的东西还很多,因此还需要根据实际情况来解决问题。时刻记住“测试就是不要怕麻烦”,问题总会解决。

责任编辑:admin
关键字:
输入手机号马上下载: