現在先來總結一下到底上面說的模型存在著哪些問題：
1、客戶生氣地說：這個產品好像不是我們想要的吧！早知你們給我這樣子的產品，我才不會下單了，你們也早點跟我說這個產品是這樣子，到現在才給我看，浪費我時間，精力，我不買了！（客戶到交付后來發現產品與當初他們提的需求不一致，所以很生氣，后果很嚴重）
2、設計團隊激動地說：都開發了這么長時間了，你們還要改功能加功能啊，這樣子會影響到很多其他功能的，會影響最后發布時間的，而且最后的質量如何，我不能保證。（老兄，我出錢買你們產品的好吧，我想加什么功能改什么功能當然得給我弄好，不然我不付錢了！）
3、開發人員暴跳如雷地說：你們這幫測試，早不提晚不提，總是在最后要發布前給我們提這么多Bug，是不是存心給我們找茬啊！要是不能準時發布，你們負責啊！（測試人員委屈地說：我們也想能早點發現這個Bug，早點修好這個Bug啊，但是之前你們也沒我Build測啊！）
就這樣，不斷地出現相互的抱怨，也就是所謂的矛盾，哲學上說，矛盾是事物發展的動力，所以這些矛盾的出現，也就是預示著，我們需要有解決這些矛盾的方法，很慶幸，我們的很多前輩已經幫我們解決了這方面的問題，準確地說是從理論上解決了這種問題，且聽我慢慢道來。
首先，對于客戶能否得到自己想要的產品這個問題，以前得不到的原因無非就是兩點：
第一個就是我們一開始設計的需求點其實跟客戶所想要的需求不一致。這一點，我們可以通過需求設計完成后馬上跟客戶確認就可以解決。
第二點就是客戶只能等到最后時刻才能看到這個產品，也就意味著，即使他們發現自己以前的想法是不對的，想要改一下自己的想法卻來不及了，因為產品已經出來了，再去改可能又要等很長時間了，這個誰也拖不起。這一點，我們可以通過經常給客戶交付一個可用的Build，讓客戶去看已經實現的功能，來研究是否還需要更改。
而對于我們的設計團隊來說，上面的第二點也正好可以解決他們的問題，由于有可用的Build，所以我們設計好的功能一做完就可以馬上讓客戶看到，一旦要修改些什么，就不會再像以前那樣由于所有功能點都做完了，改一個就牽一發而動全身了，這點也類似之前說的，一個Bug發現的越早修得成本越低。
而對于咱們的開發人員和測試人員而言，為了幫助客戶得到自己想要的產品，也需要做些改變，不過也很簡單，幾句話而已，開發完成一個功能以后，測試人員就要測試這個功能，然后開發人員需要把發現的Bug馬上修掉，最后測試需要把修復的Bug確認修復。這樣子的話，就可以解決以前最后階段才能開展測試，才能發現大量Bug，導致發布成本增加、延期等不確定因素的發生。
當然，這里還有一點必須說一下，即使采用了新方法，成本增加，時間延期這種事情還是有可能發生，但是新的方法可以讓你預測到可能發生的成本與時間問題，不會像以前那樣到最后時刻才會發現，這樣子對于領導層做決策還是會有很大幫助的。
講到這里，大家應該發現，測試流程已經完全與開發流程并行了，之前說的W模型雖然也會有并行，但是只是屬于“偽并行”，因為它需要一個階段結束才能進行下個階段，比如開發完所有的功能以后才能開始測試，而對于這個模型，測試自始至終一直在參與著測試，不會去管哪個階段是否完成，只在乎哪個功能已經設計好，已經開發好。對于設計好的功能，測試里也有專門的設計測試工程師（Design QA）去專門檢查這個設計是否符合客戶的要求，甚至會去和客戶做溝通；對于開發好的功能，一方面代碼完成后開發需要馬上進行單元測試，然后專職測試人員拿到Daily Build以后就要馬上常規測試，看看是否工作，發現嚴重Bug馬上提上去讓開發修；最后所有功能都已經確認和測試完畢后，測試人員還要再繼續進行集成測試、系統測試和壓力測試等等；甚至到了后來的維護階段還需要測試人員繼續參與，因為很多技術支持人員對產品沒有測試人員了解地多，所以碰到難的問題，還需要測試人員的幫忙。
所以從一開始的設計到最后的發布，測試人員一直全程參與著，這個跟以前的模式已經有了非常大的改變了，對測試人員的要求和壓力已經是不可同日而語了。這個新的模式也就是敏捷測試模式的雛形了，當然還并非完全的敏捷測試模式，所以我暫時先把它稱之為準敏捷模式。
既然有了準敏捷模式，那什么才是真正的敏捷測試模式呢？呵呵，還是聽下回分解吧。
（未完待續）