敏捷這個話題似乎熱了好多年，隨之也就自然地有了
敏捷測試這個術語。
說到敏捷，大家一定聽過不少相關的演講，看到不少相關的書籍，不過不管有什么新的技術，新的流程，歸根結底都是遵循著敏捷宣言并以敏捷原則作為根本。就像Scrum開拓了一套敏捷
項目管理的框架，XP指導著敏捷開發中的工程實踐一樣，敏捷測試也就是一組指引測試
工作在敏捷團隊中的一些最佳實踐。
首先，敏捷測試非常強調和多方的合作。在瀑布開發模式下，測試人員一般是根據需求文檔和設計文檔來設計
測試用例，然后等功能開發完成，軟件交付到測試人員手上才開始正式的測試工作，這樣對于測試的所有輸入就都是文檔。而敏捷測試讓測試人員在
軟件開發的最初就加入團隊，為的就是使測試人員更加地靠近產品本身，對于產品經理的需求和開發人員的設計有深入的理解，甚至能和后續的部署和運維團隊盡早地接觸，了解到產品的全方位。
再次，盡早地使產品可以測試起來，越早越好。測試工作不再是軟件開發中的某一個環節，而是時時刻刻貫穿于軟件開發中。實現這一點的基礎就是軟件的可測性，而可測性又包括至少兩點
有較為明確的需求指標（這里使用了“較為”兩個字是因為有些非功能上的指標前期可能的確不太明了，但是隨著產品開發的進行，最終還是會慢慢清晰的），這樣才能對測試結果進行判定
有適合測試的接口，這樣才能方便的設計和執行測試用例，并能最大規模地發揮測試自動化的優勢
之后，使團隊一起加入測試。千萬不要孤軍奮斗，
軟件測試是一件極其需要團隊力量的過程，讓策劃/開發/運維甚至是產品經理一起加入。
編寫用戶驗收測試用例的時候要邀請策劃和產品經理，避免對于需求的理解錯誤
請運維一起加入產品的部署測試，他們有著更多的生產環境的實際操作經驗
當然每個角色對于加入的方式可能會不太相同，但是重要的一點就是把所有的測試環節都對團隊成員透明，讓他們知道產品會進行哪些測試，已經進行了哪些測試，當前的測試結果怎么樣。
在測試可以跑起來之后，盡量頻繁地測試。說到這個，測試自動化很自然地被提上了日程。注意，這里用的是“測試自動化”，而不是“
自動化測試”。個人認為測試自動化不僅僅是把測試用例通過編寫代碼腳本化并通過機器運行起來，而是包含了一套對于測試過程的自動化，包括測試環境的自動部署，測試數據的自動生成，測試腳本的自動執行和測試結果的自動報告等等。好了，回到“頻繁地測試”這個話題，我們需要多頻繁呢？越頻繁越好！
每一次的代碼（產品代碼或是測試代碼）提交或是每一次的配置更新都有潛在破壞軟件的可能性，都是需要測試的
產品在不同部署環境中的表現往往是不可預料的，盡可能多的對可能的部署環境進行驗證
即使部署環境和產品都沒有變化，也需要重復測試。這個可能會有些疑問，既然什么都沒變，已經跑過通過的測試還有必要重復執行嗎？答案是“有必要”
· 產品在剛啟動時和運行了一段時間之后的表現是完全不同的，看似重復執行的測試其實已經是運行在不同狀態下的
· 測試的執行往往是按照一定順序的，依據“殺蟲劑”原理，系統是會有一定“抵抗力”的，這時可以不采取簡單的重復測試，而是打亂測試順序（雖然測試用例的設計在原則上是獨立的，但是在實際中對于軟件產品的內部狀態變化是不可預知的）
上面這些只是敏捷測試個人的一些理解，其中并沒有涉及到具體技術層面的東西，更多的是一種思想層面對于軟件測試的轉變
· 軟件測試是軟件開發的一部分
· 軟件測試是團隊成員的職責
· 軟件測試需要盡早，自動，頻繁的執行
也正是因為有了這些需求，TDD/ATDD/CI才會被團隊所接受，慢慢變成了一種標配