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

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

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

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

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

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

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

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

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

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

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

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

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

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