對于敏捷開發中的測試，其實之前我也是認為很有必要的。
對于一個敏捷開發過程（或者按照周博士的話叫做混合型的敏捷開發過程）而言，我覺得測試這個過程不是一個單一的過程，因為它不是只在某一個階段開展的，而是在整個過程中無時無刻不見它。
1、需求階段：
當一個需求被設計出來的時候，測試就必須介入，做什么事情呢？
第一個事情，根據這個設計文檔，開始寫測試用例
第二個事情，根據這個設計文檔，結合用戶的實際需求，從概念上看是否真的能夠符合客戶的需求（這個很重要，一旦能夠發現問題，等于給公司減少了非常多的錢，因為如果有設計問題到最后被發現，那個時候開發和測試已經投入多少力量去做了，而且所用的代碼可能會影響到其他程序的運行，要改回來，代價是很大的。）
2、開發階段：
雖然開發階段是開發人員的事情，但是測試人員同樣必須介入：
第一個事情，開發人員完成代碼后，白盒測試人員需要介入進去。
第二個事情，開發人員進行開發時，需要確保他們的開發能否符合測試用例中的測試點的要求。（我們知道，測試人員與開發人員的思想不是很一致，那天周博士也舉了下拉框那個例子就能很好的說明問題，所以現在的情況是，測試人員已經提前把很多測試的點列出來，雖然還有不少點可能會在實際測試中發現，但是開發人員在開發階段如果能把測試用例中這些測試點都覆蓋得很好，那么產品質量從初期就已經在一個正確的道路上前進了。當然如果開發人員自顧自，覺得怎么做就怎么做，到后來發現不符合設計思想，然后去返工，這種后果造成的影響大家都能想象得到。）
3、測試階段：
這個測試階段的確是傳統上測試人員拿到產品開始測試的階段，但是它也不是一個單一的階段，也需要很多不同的階段組成。
第一個階段：迭代測試階段
這個階段中，需要把當前迭代中完成的功能進行測試，完成一個就測試一個。在敏捷中，理論上每天都會有很用的Build讓測試人員可以測試，所以一旦一個功能開發完成了以后，必然我們能夠馬上得到一個Build開展測試，發現重要的Bug就可以馬上修復。
這個階段非常重要，因為這是一個造成代價最小的階段，首先開發剛完成功能，修起Bug來輕車熟路，另外一點，這個代碼還沒有被其他一些功能所調用，所以對其他地方造成的影響還不會很大。
所以測試人員需要在這個階段投入大量人力去保質保量完成。
第二個階段：多迭代集成測試階段
當幾個迭代已經過去了，有很多功能已經做好了以后，這個時候考慮到雖然單個功能看起來都還好，但是這么多功能現在都做完了，是不是相互之前會影響啊，或者對于穩定性造成影響之類的的因素，有必要進行多迭代功能集成測試（也包括了回歸測試），這種測試比較多的是在類似Alpha Release，Beta Release的時候進行。
第三個階段：系統性綜合測試階段
當所有迭代都完成以后，當然我們還是需要進行一次全方位的測試（當然也包括負載測試、性能測試等），這個就比較類似傳統那個測試階段了，這里就不多說了。
我們看得出，測試這塊在SpecDD中占了很大一個地位，而且更重要的是，它是一個不固定的過程，在SpecDD中幾乎每個過程都是需要測試這個過程存在的，所以它被稱之為“流浪漢“也比較貼切，或者叫”濟公“也不錯，因為“哪里不平哪有我”。
相關鏈接：
什么是SpecDD？