软件测试中敏捷：系统测试的噩梦
很早就听说过敏捷软件开发的概念，觉得是个新生事物，挺好玩，现在IT的炒作已经太多了，后来发现敏捷的思想越来越深入人心，大大小小的公司开始使用敏捷的模式进行软件开发。终于，敏捷来到了我的身边。
首先敏捷测试是敏捷的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。 敏捷测试是遵循敏捷宣言的一种测试实践： 1、强调从客户的角度，即使用系统的用户的角度，来测试系统。 2、重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。 3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
在传统的软件开发模式中，系统测试属于软件开发过程的较后阶段，基本是在所有开发代码全部完成，开发人员拿出所有精力修改bug时才会正式进行系统测试，包括安装啦、稳定性啦、负载啦等等。
这次项目开始大约半年了，是一个小版本的升级，采用了scrum模式，我切实的感觉到敏捷系统测试不太对劲。在scrum中，根据开发的实际情况，设定一个时间间隔（比如每两个周）为一个sprint周期，每个周期都有需求跟踪和实现，然后在进入下一个sprint阶段。
目前，我发现了几个敏捷系统测试的主要问题：
不断增加的新功能导致测试结果失效。
既然是敏捷，当然是时刻适应需求的变化，于是功能不断的改变。系统测试的结果在一次次的代码变化之后失效，比如测试应用的稳定性，跑了两天，内存和其他参数都没问题，然后开发人员在下一个sprint对代码做了很多修改，你说要不要重测？？通常这种回归测试都是在系统测试的最后阶段，拿到最后的build的之后再测，现在呢，不得不测，如果说系统测试的工作量少也就算了，但事实上，系统测试的压力特别大，搞的大家身心疲惫。
发现问题，开发人员无法适当处理。
如果在测试中发现了问题，按理说开发人员应该尽快解决，但在敏捷开发模式下，开发人员每一个sprint都有相应的需求要实现，精力有限，于是他们对于细微的bug根本置之不理，一般都会拖到最后才解决，这就导致了一个问题， 这些bug在若干次build之后会不会重现，可能在报完bug之后3个月，开发人员才开始考虑这个问题，此时这个bug报告还有效吗？？是不是需要重新测试？？于是我们测试人员之前的测试工作根本没意义了。另一方面，对于严重的bug，开发人员也无法集中全部精力来处理，三心两意，你说bug能解的顺利吗？后果就是开发人员和测试人员都满心抱怨。
在我看来，这种紧跟敏捷的系统测试不是完全没有意义，有些严重bug可以提早发现，开发人员可以尽早解决，但是体现了帕累托现象：我们用80%的努力得到了软件质量20%的提高，的确，从公司老板的角度看，这样值得，反正软件质量提高了，但对于开发和测试人员来说确实非常痛苦。我记得敏捷的思想来自于计算机界的各位大牛，他们在设计软件开发模式时，没有考虑过系统测试的特殊性吗？还是他们从没把系统测试包含在敏捷思想里面，只是某些人狂热的把敏捷错误的用到了系统测试当中？
文章来源于领测软件测试网 https://www.ltesting.net/
