敏捷测试理论以及实践（3）

敏捷测试理论以及实践（3）

　　现在先来总结一下到底上面说的模型存在着哪些问题：

　　1、客户生气地说：这个产品好像不是我们想要的吧！早知你们给我这样子的产品，我才不会下单了，你们也早点跟我说这个产品是这样子，到现在才给我看，浪费我时间，精力，我不买了！（客户到交付后来发现产品与当初他们提的需求不一致，所以很生气，后果很严重）

　　2、设计团队激动地说：都开发了这么长时间了，你们还要改功能加功能啊，这样子会影响到很多其他功能的，会影响最后发布时间的，而且最后的质量如何，我不能保证。（老兄，我出钱买你们产品的好吧，我想加什么功能改什么功能当然得给我弄好，不然我不付钱了！）

　　3、开发人员暴跳如雷地说：你们这帮测试，早不提晚不提，总是在最后要发布前给我们提这么多Bug，是不是存心给我们找茬啊！要是不能准时发布，你们负责啊！（测试人员委屈地说：我们也想能早点发现这个Bug，早点修好这个Bug啊，但是之前你们也没我Build测啊！）

　　就这样，不断地出现相互的抱怨，也就是所谓的矛盾，哲学上说，矛盾是事物发展的动力，所以这些矛盾的出现，也就是预示着，我们需要有解决这些矛盾的方法，很庆幸，我们的很多前辈已经帮我们解决了这方面的问题，准确地说是从理论上解决了这种问题，且听我慢慢道来。

　　首先，对于客户能否得到自己想要的产品这个问题，以前得不到的原因无非就是两点：

　　第一个就是我们一开始设计的需求点其实跟客户所想要的需求不一致。这一点，我们可以通过需求设计完成后马上跟客户确认就可以解决。

　　第二点就是客户只能等到最后时刻才能看到这个产品，也就意味着，即使他们发现自己以前的想法是不对的，想要改一下自己的想法却来不及了，因为产品已经出来了，再去改可能又要等很长时间了，这个谁也拖不起。这一点，我们可以通过经常给客户交付一个可用的Build，让客户去看已经实现的功能，来研究是否还需要更改。

　　而对于我们的设计团队来说，上面的第二点也正好可以解决他们的问题，由于有可用的Build，所以我们设计好的功能一做完就可以马上让客户看到，一旦要修改些什么，就不会再像以前那样由于所有功能点都做完了，改一个就牵一发而动全身了，这点也类似之前说的，一个Bug发现的越早修得成本越低。

　　而对于咱们的开发人员和测试人员而言，为了帮助客户得到自己想要的产品，也需要做些改变，不过也很简单，几句话而已，开发完成一个功能以后，测试人员就要测试这个功能，然后开发人员需要把发现的Bug马上修掉，最后测试需要把修复的Bug确认修复。这样子的话，就可以解决以前最后阶段才能开展测试，才能发现大量Bug，导致发布成本增加、延期等不确定因素的发生。

　　当然，这里还有一点必须说一下，即使采用了新方法，成本增加，时间延期这种事情还是有可能发生，但是新的方法可以让你预测到可能发生的成本与时间问题，不会像以前那样到最后时刻才会发现，这样子对于领导层做决策还是会有很大帮助的。

　　讲到这里，大家应该发现，测试流程已经完全与开发流程并行了，之前说的W模型虽然也会有并行，但是只是属于“伪并行”，因为它需要一个阶段结束才能进行下个阶段，比如开发完所有的功能以后才能开始测试，而对于这个模型，测试自始至终一直在参与着测试，不会去管哪个阶段是否完成，只在乎哪个功能已经设计好，已经开发好。对于设计好的功能，测试里也有专门的设计测试工程师（Design QA）去专门检查这个设计是否符合客户的要求，甚至会去和客户做沟通；对于开发好的功能，一方面代码完成后开发需要马上进行单元测试，然后专职测试人员拿到Daily Build以后就要马上常规测试，看看是否工作，发现严重Bug马上提上去让开发修；最后所有功能都已经确认和测试完毕后，测试人员还要再继续进行集成测试、系统测试和压力测试等等；甚至到了后来的维护阶段还需要测试人员继续参与，因为很多技术支持人员对产品没有测试人员了解地多，所以碰到难的问题，还需要测试人员的帮忙。

　　所以从一开始的设计到最后的发布，测试人员一直全程参与着，这个跟以前的模式已经有了非常大的改变了，对测试人员的要求和压力已经是不可同日而语了。这个新的模式也就是敏捷测试模式的雏形了，当然还并非完全的敏捷测试模式，所以我暂时先把它称之为准敏捷模式。

　　既然有了准敏捷模式，那什么才是真正的敏捷测试模式呢？呵呵，还是听下回分解吧。

　　（未完待续）