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

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

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

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

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

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

 [案例補(bǔ)充]

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