敏捷方法在軟件開發中受到青睞，特別是在互聯網應用服務系統的開發中，越來越多的公司採用敏捷方法，包括XP、Scrum、Lean、Crystal、FDD等。具體的敏捷方法在操作時有一些區別，但基本思想是一致的，如客戶至上、擁抱變化、縮短迭代週期、自我組織等。在敏捷方法中，流程相對靈活，強調溝通，通過充分的溝通來及時解決問題，由於溝通充分，文檔不是很重要，而且有可能不採用Word等獨立的文件格式，而是採用Wiki、空間等web內容方式。在敏捷方法中，需求變化比較快、產品開發週期很短（一、兩週），給軟件測試帶來很大的挑戰！例如，功能測試的自動化實現就比較困難，沒有足夠時間開發自動化測試腳本，要花大量時間討論產品特性，及時進行產品的驗收測試。自動化測試，更多的是在單元測試這個層次上實現。而單元測試自動化、持續集成等一些關鍵實踐，開發人員能發揮更大的作用，而測試人員難以很好地發揮作用。在敏捷方法中，開發人員的主導作用更明顯，討論需求、實現需求，再修改需求、再實現、再重構，不斷完善產品，測試人員容易邊緣化。甚至在Crystal方法中，可以不需要測試人員，開發人員能承擔所有技術性的工作。
在敏捷方法中，測試人員的價值又如何體現？
首先在需求討論上，測試人員可以站在客戶角度上來闡述自己的觀點，和產品人員、開發人員等進行充分的交流和討論，使自己在用戶體驗、業務邏輯等等方面的經驗充分體現出來。
在開發過程中，測試人員不僅扮演“用戶代表”角色，而且可以及時提供更全面的質量反饋，包括代碼質量、接口一致性等。測試人員不寫代碼，可以參與代碼複審（code review），將質量問題及時提交給項目組，保證在產品構造的整個過程中質量受到足夠的關注，提高質量改進的持續性和可視性。
測試人員還是可以參與單元測試。即使單元測試由開發人員做，測試人員可以推進開發人員進行單元測，檢查單元測試狀態，如確保單元測試達到80%以上覆蓋率，以及幫助開發人員開發出具有良好可測試性的代碼。
即使在敏捷方法中，集成測試、端到端（end-to-end）測試、性能測試等是不可少的。因爲在敏捷方法中，往往將一個大的系統開發分解成多個小的子系統（模塊/組件），集成測試和端到端（end-to-end）測試顯得更重要。測試人員在功能測試上工作量會降低，但在這些測試上發揮更大的作用。
隨着迭代的不斷深入，迴歸測試的工作量很大，這也是測試人員的用武之地。 測試人員可以針對穩定的產品特性開發自動化測試腳本，這也是一種持續的努力，使迴歸測試自動化。
測試人員對缺陷進行分析，總結出一些規律，幫助開發人員建立良好的習慣，改進代碼的質量。
而且：
在敏捷方法中，我們也要採用敏捷測試，不要再寫幾十頁的測試計劃書，而是在每個迭代週期，寫出一頁紙的測試計劃，將測試要點列出來。
在敏捷測試中，可能不需要測試用例，而是針對use case 或user story直接進行驗證，並進行探索性測試。而節約出來的時間，用於開發原有功能的自動化測試腳本，爲迴歸測試服務。自動化測試腳本將代替測試用例，成爲軟件組織的財富。
所以：
敏捷功能測試 = 新特性的手工測試 (use case驗證和探索性測試) + 原有功能的自動化測試 (迴歸測試)
理想情況下，測試人員具有很好的編程能力，可以和開發人員進行角色互換。在當前版本開發（/迭代週期）中擔任測試人員角色，在下一個版本開發（/迭代週期）中擔任開發人員角色，而開發人員則擔任測試人員角色，讓開發人員深刻地理解用戶的需求角度來考慮系統功能的設計，這樣會更好地保證產品的質量，溝通的障礙也會消除，開發的效率會有很大的提高。這也是對測試人員的一個挑戰。
敏捷測試也是一個持續測試的過程，而這持續測試的基礎是具備一個靈活的、開放的自動化測試框架。測試人員在自動化測試框架構建上、測試工具開發或第3方測試工具前期研究、試用等方面可以發揮主導作用。
項目採用敏捷方法，要獲得成功，項目組中每個人都有很強的質量意識，具有質量的主人翁精神，特別是開發人員，每時每刻提醒自己——“質量是構建出來的”，與客戶或產品設計人員進行充分溝通，遵守高度一致的質量標準。測試人員將是促進質量文化不斷提升的中堅力量。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/KerryZhu/archive/2010/03/10/5366574.aspx