敏捷是否是系统软件测试的噩梦?

发表于:2009-07-15来源:作者:点击数: 标签:系统测试工具噩梦系统软件
敏捷是否是系统 软件测试 的噩梦? 系统测试工具 很早就听说过敏捷软件 开发 的概念,觉得是个新生事物,挺好玩,现在IT的炒作已经太多了,后来发现敏捷的思想越来越深入人心,大大小小的公司开始使用敏捷的模式进行软件开发。终于,敏捷来到了我的身边。 在

敏捷是否是系统软件测试的噩梦? 系统测试工具

很早就听说过敏捷软件开发的概念,觉得是个新生事物,挺好玩,现在IT的炒作已经太多了,后来发现敏捷的思想越来越深入人心,大大小小的公司开始使用敏捷的模式进行软件开发。终于,敏捷来到了我的身边。

  在传统的软件开发模式中,系统测试属于软件开发过程的较后阶段,基本是在所有开发代码全部完成,开发人员拿出所有精力修改bug时才会正式进行系统测试,包括安装啦、稳定性啦、负载啦等等。

  这次项目开始大约半年了,是一个小版本的升级,采用了scrum模式,我切实的感觉到敏捷系统测试不太对劲。在scrum中,根据开发的实际情况,设定一个时间间隔(比如每两个周)为一个sprint周期,每个周期都有需求跟踪和实现,然后在进入下一个sprint阶段。

  目前,我发现了几个敏捷系统测试的主要问题:

  1. 不断增加的新功能导致测试结果失效。

  既然是敏捷,当然是时刻适应需求的变化,于是功能不断的改变。系统测试的结果在一次次的代码变化之后失效,比如测试应用的稳定性,跑了两天,内存和其他参数都没问题,然后开发人员在下一个sprint对代码做了很多修改,你说要不要重测??通常这种回归测试都是在系统测试的最后阶段,拿到最后的build 的之后再测,现在呢,不得不测,如果说系统测试的工作量少也就算了,但事实上,系统测试的压力特别大,搞的大家身心疲惫。

  2. 发现问题,开发人员无法适当处理。

  如果在测试中发现了问题,按理说开发人员应该尽快解决,但在敏捷开发模式下,开发人员每一个sprint都有相应的需求要实现,精力有限,于是他们对于细微的bug根本置之不理,一般都会拖到最后才解决,这就导致了一个问题,这些bug在若干次build之后会不会重现,可能在报完bug之后3个月,开发人员才开始考虑这个问题,此时这个bug报告还有效吗??是不是需要重新测试??于是我们测试人员之前的测试工作根本没意义了。另一方面,对于严重的bug,开发人员也无法集中全部精力来处理,三心两意,你说bug能解的顺利吗?后果就是开发人员和测试人员都满心抱怨。

  在我看来,这种紧跟敏捷的系统测试不是完全没有意义,有些严重bug可以提早发现,开发人员可以尽早解决,但是体现了帕累托现象:我们用80%的努力得到了软件质量20%的提高,的确,从公司老板的角度看,这样值得,反正软件质量提高了,但对于开发和测试人员来说确实非常痛苦。我记得敏捷的思想来自于计算机界的各位大牛,他们在设计软件开发模式时,没有考虑过系统测试的特殊性吗?还是他们从没把系统测试包含在敏捷思想里面,只是某些人狂热的把敏捷错误的用到了系统测试当中?

原文转自:http://www.ltesting.net