敏捷開發的最大特點是：積極響應用戶的需求，快速高質量的交付軟件。

所以很多需求會按照用戶需求程度以及模塊之間的關聯程度劃分為多個叠代，這裏的叠代你可以看做是一個小的完整的版本周期，每個叠代包含多個story，一個story相當於一個功能點，一個小的需求，而一個大的完整的發布版本一般由幾個叠代版本組成。
OK，下面就開始寫測試是從什麽時候介入以及有哪些工作的。
1、story澄清會議（即需求澄清），參與人員：開發人員、資料開發人員、測試人員、TSE、需求接口人等。目的顧名思義就是讓所有參與項目的人員更深入的了解需求，會議上任何參與者都可以發表疑問，對不理解的地方要及時問清楚，實踐證明這個會議能盡早的發現開發人員遺漏掉的功能點以及功能實現的方式對其他模塊的影響等。這個階段開發輸出的文檔有：story驗收標準。一般情況下對於功能復雜的模塊，為了讓大家跟直觀的了解功能點，一般開發人員會準備demo演示，這樣也更有利於測試人員測試用例的輸出。
2、測試人員根據需求澄清時了解的需求點編寫測試方案，然後輸出用例，完成後發給開發人員、TSE對用例進行評審，編寫人員根據檢視意見修改用例，直到大家都認可了，再導入用例管理工具TMSS。
3、叠代story轉測試之前，測試人員需要向開發人員分一部分基本功能的用例驗證，用例通過後才可以轉測試。轉測試附帶的文檔包括：代碼檢視確認報告、測試部提供用例的執行結果報告、開發自測用例樣例參考等。
4、測試人員執行測試，執行用例---提交bug---回歸問題---story評價---關閉story
5、叠代結束，回歸會議，開發測試人員一起進行此次叠代版本的優缺點分析等。
6、問題單逆向分析，分析每個問題單產生的原因，是用例設計遺漏、老版本遺留的問題還是修改引入的問題？如果是用例設計遺漏還需要補充用例的，如果是開發的修改引入比較多，那開發的麻煩就大了，是需要通報批評的。
7、測試質量報告，從發現問題多少、嚴重性以及聚焦的功能點等考慮給出A/B/C等級評價，並合理的給出建議，比如加強開自驗、加強用例輸出的標準等。

最後補充下這裏為什麽沒有測試計劃這一項，因為我們的計劃大部分都是根據開發人員的開發計劃來制定測試計劃，而且這個計劃都在叠代計劃裏面包含的。

好了，基本上大概也就是這些流程了，不知道算不算是標準的敏捷。上次在群裏一個群友說他們公司也搞敏捷，他非常的不習慣，說在軟件沒有出來前就讓寫用例真是浪費時間，因為就像是在黑夜裏走路一樣，根本就不知道怎麽寫。這一點估計大部分人都有這樣的感覺吧，包括我剛敏捷的時候也是，非常的痛苦，但是真正當我跟了兩個版本後，適應了後發現其實也不難，而且挺能鍛煉人的，寫用例的時候需要不斷的去和開發確認，從中還能了解到不少需求點呢。至於浪費時間，我倒一點都沒覺得，因為當需求澄清完後，開發人員在編寫代碼的時候，我們測試人員基本都是等著轉測試，而這個時候寫寫用例，豈不是更合理的利用了時間了呢？敏捷開發的周期一般都很短，一個月或者最多兩個月時間，節奏非常快，所以大部分人都覺得有點累，然而雖然累點，但我總感覺我是真正的在做測試，不僅僅是鼠標點點罷了，雖然他也是手工測試，因為過程不同感受不同，---個人觀點。

敏捷測試的定義