敏捷方法在軟件開發(fā)中受到青睞，特別是在互聯(lián)網(wǎng)應用服務系統(tǒng)的開發(fā)中，越來越多的公司采用敏捷方法，包括XP、Scrum、Lean、Crystal、FDD等。具體的敏捷方法在操作時有一些區(qū)別，但基本思想是一致的，如客戶至上、擁抱變化、縮短迭代周期、自我組織等。在敏捷方法中，流程相對靈活，強調(diào)溝通，通過充分的溝通來及時解決問題，由于溝通充分，文檔不是很重要，而且有可能不采用Word等獨立的文件格式，而是采用Wiki、空間等web內(nèi)容方式。在敏捷方法中，需求變化比較快、產(chǎn)品開發(fā)周期很短（一、兩周），給軟件測試帶來很大的挑戰(zhàn)！例如，功能測試的自動化實現(xiàn)比較困難，沒有足夠時間開發(fā)自動化測試腳本，要花大量時間討論產(chǎn)品特性，及時進行產(chǎn)品的驗收測試。自動化測試，更多的是在單元測試這個層次上實現(xiàn)。而單元測試自動化、持續(xù)集成等一些關鍵實踐，開發(fā)人員能發(fā)揮更大的作用，而測試人員難以很好地發(fā)揮作用。在敏捷方法中，開發(fā)人員的主導作用更明顯，討論需求、實現(xiàn)需求，再修改需求、再實現(xiàn)、再重構(gòu)，不斷完善產(chǎn)品，測試人員容易邊緣化。甚至在Crystal方法中，可以不需要測試人員，開發(fā)人員能承擔所有技術(shù)性的工作。

    在敏捷方法中，測試人員的價值又如何體現(xiàn)？

    首先在需求討論上，測試人員可以站在客戶角度上來闡述自己的觀點，和產(chǎn)品人員、開發(fā)人員等進行充分的交流和討論，使自己在用戶體驗、業(yè)務邏輯等等方面的經(jīng)驗充分體現(xiàn)出來。在開發(fā)過程中，測試人員不僅扮演“用戶代表”角色，而且可以及時提供更全面的質(zhì)量反饋，包括代碼質(zhì)量、接口一致性等。測試人員不寫代碼，可以參與代碼復審（code review），將質(zhì)量問題及時提交給項目組，保證在產(chǎn)品構(gòu)造的整個過程中質(zhì)量受到足夠的關注，提高質(zhì)量改進的持續(xù)性和可視性。
測試人員還是可以參與單元測試。即使單元測試由開發(fā)人員做，測試人員可以推進開發(fā)人員進行單元測，檢查單元測試狀態(tài)，如確保單元測試達到80%以上覆蓋率，以及幫助開發(fā)人員開發(fā)出具有良好可測試性的代碼。
即使在敏捷方法中，集成測試、端到端（end-to-end）測試、性能測試等是不可少的。因為在敏捷方法中，往往將一個大的系統(tǒng)開發(fā)分解成多個小的子系統(tǒng)（模塊/組件），集成測試和端到端（end-to-end）測試顯得更重要。測試人員在功能測試上工作量會降低，但在這些測試上發(fā)揮更大的作用。
隨著迭代的不斷深入，回歸測試的工作量很大，這也是測試人員的用武之地。 測試人員可以針對穩(wěn)定的產(chǎn)品特性開發(fā)自動化測試腳本，這也是一種持續(xù)的努力，使回歸測試自動化。
    測試人員對缺陷進行分析，總結(jié)出一些規(guī)律，幫助開發(fā)人員建立良好的習慣，改進代碼的質(zhì)量。
而且：在敏捷方法中，我們也要采用敏捷測試，不要再寫幾十頁的測試計劃書，而是在每個迭代周期，寫出一頁紙的測試計劃，將測試要點列出來。
在敏捷測試中，可能不需要測試用例，而是針對use case 或user story直接進行驗證，并進行探索性測試。而節(jié)約出來的時間，用于開發(fā)原有功能的自動化測試腳本，為回歸測試服務。自動化測試腳本將代替測試用例，成為軟件組織的財富。
所以：敏捷功能測試 = 新特性的手工測試 (use case驗證和探索性測試)  + 原有功能的自動化測試 (回歸測試)

     理想情況下，測試人員具有很好的編程能力，可以和開發(fā)人員進行角色互換。在當前版本開發(fā)（/迭代周期）中擔任測試人員角色，在下一個版本開發(fā)（/迭代周期）中擔任開發(fā)人員角色，而開發(fā)人員則擔任測試人員角色，讓開發(fā)人員深刻地理解用戶的需求角度來考慮系統(tǒng)功能的設計，這樣會更好地保證產(chǎn)品的質(zhì)量，溝通的障礙也會消除，開發(fā)的效率會有很大的提高。這也是對測試人員的一個挑戰(zhàn)。

    敏捷測試也是一個持續(xù)測試的過程，而這持續(xù)測試的基礎是具備一個靈活的、開放的自動化測試框架。測試人員在自動化測試框架構(gòu)建上、測試工具開發(fā)或第3方測試工具前期研究、試用等方面可以發(fā)揮主導作用。

    項目采用敏捷方法，要獲得成功，項目組中每個人都有很強的質(zhì)量意識，具有質(zhì)量的主人翁精神，特別是開發(fā)人員，每時每刻提醒自己??“質(zhì)量是構(gòu)建出來的”，與客戶或產(chǎn)品設計人員進行充分溝通，遵守高度一致的質(zhì)量標準。測試人員將是促進質(zhì)量文化不斷提升的中堅力量。

 [案例補充]

來HW一段時間了，所在項目是其一個全新重點項目，由于采用敏捷模式開發(fā)，包括PM在內(nèi)大家都是在摸索中進行的。撇開CMM改用敏捷，文檔不再全面了，連缺陷庫都改用輕量級的了，領導們說敏捷中測試做的好不好不是看找到多少BUG，而是看轉(zhuǎn)測試時有沒有BUG，要在開發(fā)交流中解決全部問題。三輪迭代下來，交流占據(jù)了大多數(shù)時間，感覺工作做好很多，但卻不知道如何體現(xiàn)，這個真是問題，希望大家給點建議。