敏捷軟件開發與其他軟件開發方法學最大的區別，在于敏捷是承認并擁抱變化的。為了這樣的變化，敏捷的不同方法，比如極限編程、Scrum引入不同的技術實踐和流程，像持續集成、測試驅動開發以及短迭代周期等，來確保即使在需求的快速變化下，也能保證交付的軟件總是滿足用戶的需求，是高質量的價值交付。
從敏捷軟件開發宣言來看，并沒有涉及測試的內容，更不用提為QA即測試人員提供指導性的建議。就是以極限編程的14個推薦實踐來看，表面上對于測試的提及也只是驗收測試，甚至沒有敏捷測試這個概念。這樣讓很多人一度認為敏捷軟件開發是不是之以程序開發為導向的，是不是我們測試人員能從敏捷獲得的直接支持少之又少，我們是不是被遺忘的一個種群？
答案必然是否定的。還以極限編程為例，除了驗收測試以外，極限編程提及的完整團隊、用戶故事、短交付周期、持續集成等實踐，都在從不同的維度對于測試工作的流程和方式甚至對它思考的角度提出了變化的要求。
完整團隊從文化氛圍和組織結構上明顯區別與過往的測試人員參與感，測試人員不再是對軟件系統質量負責的唯一角色，對質量負責的是全體團隊成員的職責。用戶故事改變以前對于軟件系統功能和模塊的劃分，而是從交付的獨立價值出發，改變了測試人員對于測試案例準備和驗收的方法。短交付周期，無論是兩周還是四周，都給整個團隊帶來了巨大的變化，開發和測試不再是獨立而又順序的過程，開發和測試互相穿插，成為一個快速反饋的過程。持續集成是軟件系統開發過程的晴雨表，其中價值相當大的自動化測試仍然和我們的測試工作脫不了干系。
可見，敏捷和它的方法，雖然沒有顯式地給測試工作以指導建議，但隱式地要求了我們測試人員仔細思考測試本身在敏捷項目中所需要發生的變化，我們測試人員的職責和工作范疇發生了哪些變化。
與敏捷開發一樣，敏捷測試針對不同的項目上下文和不同的團隊組成和背景，有不同的適配模式。跟敏捷軟件開發的宣言類似，敏捷測試也有一系列可以恪守的原則。經過不斷實踐和經驗，ThoughtWorks的同事同樣提出了《敏捷測試宣言》：
1、Collaborative ownership over detached objectivity
2、Targeted automation over widespread anti-regression
3、Defect prevention over defect reporting
4、Exploratory testing over predetermined scripting
第一點與完整團隊有關。雖然獨立的測試團隊可以從外部視角觀察軟件質量，但真正的軟件質量來自測試人員屬于一部分的完整團隊，不再區分彼此的開發團隊和測試團隊，不再有彼此分離的目標。整個團隊為軟件質量和客戶價值共同負責。
第二點針對性自動化測試勝過廣泛的回歸測試。隨著軟件系統開發的進展，后期引入的新功能和缺陷都會帶來大量和重復的回歸測試，自動化測試是代替人工繁瑣而無聊的回歸測試的唯一辦法。
第三點提到的如何對待缺陷恐怕是時下各個測試團隊最為糾結的內容了。預防缺陷勝過報告缺陷，預防缺陷才是測試工作最大的價值所在。敏捷測試會盡早介入軟件系統的開發過程，和業務分析師、客戶分析需求和價值所在，以用戶故事和驗收條件來驅動開發，以短周期迭代和持續集成為反饋，可以盡早發現存在的缺陷，從而極大降低后期才報告以及修復缺陷所帶來的高額成本。在我的團隊，測試人員甚至可以和開發人員結對，共同確認缺陷根源，修復缺陷，并添加自動化測試確保缺陷不會再次發生。
第四點的探索性測試的重要性沒有人會懷疑，測試人員可以憑借自己的經驗積極、自由地發現質量問題，而不僅僅是反復運行已經定義好的測試。這樣可以證明軟件不僅僅做了它該做的事情，還證明軟件沒有做它不該做的事情。