簡介
同是企業WEB應用程序項目，一個用敏捷，一個用瀑布流程，它們的測試策略會有何不同？在二者中，測試的關注點都在於告訴業務客戶這個應用程序做了哪些事情，同樣也要消除應用程序作爲產品交付以後的失敗風險。它們的主要區別不是測試本身，而是何時執行測試、由誰執行測試。測試的每個階段都可以在系統就緒後隨時開始，無須等待前一個測試階段完成。
從未涉足敏捷項目，或是剛啓動某個敏捷項目並在尋找指導建議的讀者都可以看看這篇文章，它正是爲你們而寫。文中的信息雖並非筆者新創，但也是收集整理的結果，希望這些信息能幫助你們朝着更爲敏捷的過程邁進。
敏捷項目的測試階段跟瀑布項目的測試階段幾乎毫無二致。每個階段都有準出標準，但是在進入某個測試階段之前，是不需要等待整個應用程序完成的。只要應用程序所完成的部分足以進入下一個測試階段就行。因爲測試的對象是一個已完成的功能，而不是一個發佈，所以測試階段是在持續並行進行的。於是就有了一大堆迴歸測試。這便也意味着迴歸測試是測試自動化的基礎。對於敏捷項目而言，環境與資源也是要注意的地方，因爲對測試環境的需求會來得更早、更加頻繁。
“快速失敗”是敏捷項目的一句格言，它的含義是儘可能早地判斷出應用程序無法滿足業務需求。要做到這一點，就需要不斷地對解決方案是否滿足業務需求進行檢測，一旦不滿足，就要儘早把問題解決。敏捷團隊成員-開發人員、測試人員、架構師、業務分析師以及業務代表等人都關注於盡早交付業務價值。所以，測試需要所有團隊成員協力來做， 它不僅僅是測試人員的責任。
測試分類
敏捷項目跟瀑布項目的測試分類幾乎是一樣的。其差別主要在於大部分精力投入的地方和每個測試階段所執行的時機。敏捷項目傾力關注單元測試和功能測試，從而爲稍後執行的測試階段創造出高質量的代碼，於是後期就不會發現本應在早期發現的缺陷，並能專注於所需要測試的領域。而瀑布項目就有一個常見的問題，後期測試的焦點總是放在找出本來應該在前期發現的缺陷身上。於是修復缺陷的成本提高了，測試工作的投入翻番了，測試的關注點也偏離了。
瀑布項目和敏捷項目另外一個巨大的不同在於測試自動化。敏捷項目力求在所有測試領域內都達到100%自動化。測試跟持續構建系統集成在一起，於是當代碼發生變化時，這個變化會被自動檢測到，應用程序被構建起來，然後所有的測試都會被執行。
測試驅動開發（TDD）在敏捷項目中很常用，用這種方法的時候，測試用例比代碼要先一步創建。於是我們就可以越來越多地看到爲代碼和功能創建的測試用例。用自動化測試來驅動開發，然後消除重複，這種做法可以保證無論複雜度多高，任何開發者都可以寫出可靠的、沒有bug的代碼。TDD常用的地方是單元測試，但也同樣可以用於功能測試、集成測試、用戶驗收測試和性能測試。
單元測試
單元測試又稱白盒測試，它要測試所開發出來的每一個模塊。瀑布項目不關注這個測試階段，而且大多數時候即便有的話也是隨意爲之。敏捷項目強調單元測試，而且會把所有單元測試都自動化。自動化的單元測試是敏捷項目的基礎，對持續集成和重構起輔助作用。
單元測試應當考慮以下幾點：
1、用stub和mock來消除對外部接口的依賴。
2、由創建代碼的開發人員編寫單元測試。
3、單元測試要能自動化執行，而且要被包含在持續開發構建中。
4、單元測試之間不能有依賴，讓每一個單元測試都能獨立執行。
5、任何開發人員都要能在他自己的機器上執行單元測試。
6、用代碼覆蓋率來判斷哪些部分的代碼沒有被單元測試覆蓋。
7、在檢入代碼的修改之前，要保證單元測試100%通過。
任何測試失敗都表示構建失敗。
功能測試
功能測試常常跟系統測試相關聯，它的重點是測試應用程序的功能（包括負面測試和邊界條件）。在瀑布項目中，測試團隊一般是在這個階段開始測試工作。測試團隊的成員會一直等下去，直到開發者完成了所有的功能，並通過所有的單元測試之後才進入功能測試階段。 敏捷項目把功能拆分成故事，每次迭代開發一定數量的故事。每個故事都有一些驗收標準，這些標準一般都是由業務分析師和測試分析師制定的，它們也可以看作跟測試條件類似。測試分析師會根據驗收標準創建測試用例，用它們來檢測代碼行爲的完成程度。故事一旦編碼完成，而且單元測試運行通過以後，就可以運行功能測試來判斷是否滿足驗收標準了。這就意味着在敏捷項目中，只要第一塊功能已經完成編碼，功能測試就可以啓動，而且會貫穿整個項目的生命週期。
功能測試應當考慮以下幾點
1、要能自動化執行，並且進入持續構建（如果測試運行時間很多長，也可以只在開發持續構建中包含一小部分精挑細選的功能測試，而在系統集成持續構建中包含全部功能測試）。
2、在編碼之前寫下測試意圖，代碼完成後對測試進行實現。
3、把通過所有功能測試作爲故事完成的條件。
4、在應用程序安裝到另外一個環境（如試機環境或產品環境）上的時候需要執行功能測試。
任何測試失敗都表示構建失敗。
探索性測試
探索性測試又稱爲隨機測試。瀑布項目在它們的測試策略中沒有這種測試類型，不過大多數測試人員都會多少做一些探索性測試。在敏捷項目中這是個很關鍵的測試階段，因爲它可以用來檢測自動化測試的覆蓋率，並收集對於應用程序質量的反饋。它爲測試人員和業務分析師提供了一種結構化的方式去使用、去探索系統，從而找到缺陷。如果探索性測試在某個功能區域內找到了大量缺陷，那這部分的自動化測試用例就要被審覈。
探索性測試應當考慮以下幾點：
1、在系統集成環境中執行。
2、在較高的層次上監測探索性測試活動。
3、用自動化的環境設置方式來減少搭建環境的時間。
4、將破壞性測試作爲探索性測試的一部分。
集成測試
應用程序在作爲產品部署的時候，需要各個部分的協作；集成測試就是把這各個獨立的部分集成起來進行測試。瀑布項目不但會把應用程序的各個獨立模塊進行集成，還會把那些雖然不屬於項目的一部分，但是要開發當前應用程序就必須用到的一些應用程序也做集成。在敏捷項目中，獨立模塊間的集成是被持續構建所覆蓋的，所以集成測試的關注點就是那些不屬於當前項目的外部接口。
集成測試應當考慮以下幾點
1、在執行集成測試的時候，需要考慮到當前迭代還沒有開發的功能。
2、寫一些集成測試來定位特殊的集成點，以協助代碼調試，即便功能測試會調用到這些集成點也無妨。
3、將集成測試自動化，放到系統集成持續構建中。
任何測試失敗都表示構建失敗。
數據驗證
如果項目需要移植既有數據的話，就要進行數據驗證。它可以保證現有的數據被正確地移植到新的Schema中，新的數據被添加進來，舊的數據被移除。這種類型的測試在瀑布項目和敏捷項目中是被同等對待的，除了敏捷項目會盡力把它自動以外。
數據驗證應該考慮以下幾點：
1、在系統集成環境、試機環境和產品環境中都要執行。
2、儘可能地自動化。
3、要把測試放到系統集成持續構建中。
任何測試失敗都表示構建失敗。
用戶驗收測試（UAT）
UAT關注的是完整的業務過程，它用來確保應用程序能按照業務的處理方式工作並能滿足業務需求。它同樣還要從客戶、消費者、管理員等各種用戶的角度出發考慮應用程序的可用性。在瀑布項目中，這個階段通常就被用來找出應該在早期階段就被發現的bug。業務人員也會在這個階段驗證開發團隊交付的應用程序的質量。敏捷項目用UAT來確保應用程序滿足業務需求，因爲等到進入這個測試階段的時候，代碼質量已經較高了。在敏捷項目中，業務人員從早期的測試階段就開始參與，所以他們對交付的東西有更多的信心。
UAT應該考慮以下幾點：
1、首先進行手工測試，等它驗證了系統行爲以後再把它自動化。
2、把自動化測試放到系統集成持續構建中
3、讓應用程序的最終用戶親自將整個程序運行一遍，不過項目的測試人員要在旁邊協助。
4、在試機環境下執行UAT， 用作驗收。
5、只要完成了一個業務過程或者一個主要的UI組件，就要執行UAT。
任何測試失敗都表示構建失敗。
性能測試
性能測試涵蓋的範圍比較大，不過一般可以分成以下三類。
1、容量測試：獨立測試核心功能組件的容量。例如， 可以支持多個用戶併發檢索？一秒種能做多少次？等等。容量測試被用來精確度量系統的極限，還可以對容量規劃和系統的擴展性起輔助作用。
2、負載測試：側重於系統在負載下的表現。負載應該要體現出用戶所期望系統可以經受得住的流量。
3、壓力測試：關注系統在壓力下的表現。比較常用的技術是浸泡測試（soak test）；在浸泡測試中，系統會在一定的負載下持續運行一段時間，用來找出長期問題，如內存泄漏、資源泄漏等。壓力測試還會覆蓋故障轉移和恢復，例如正在工作的集羣中的一臺服務器出現問題，檢查是否可以做到故障轉移和恢復。
瀑布項目直到項目接近尾聲的時候才做性能測試，這個時候應用程序已經“完成了”開發，通過單元測試和功能測試。而敏捷項目則會盡快啓動性能測試。
性能測試應該考慮以下幾點：
1、在功能測試中設置一些性能度量，例如一個測試第一次運行要花多長時間，接下來每次又要花多久，把這些時間所佔的百分比做一下比較（上升表示有問題，下降表示良好）
2、把一些性能測試放到系統集成持續構建中去做。
3、一旦一個業務過程，或是某個規模比較大的功能或接口完工，就要做性能測試。
4、只有在試機環境中運行的時候才簽收性能測試。
任何測試失敗都表示構建失敗。
非功能性測試
非功能性測試所涵蓋的範圍很廣，性能測試通常也屬於這個話題。但是因爲性能測試是企業解決方案中很重要的一部分，而且需要不同的資源和技能集，所以就被劃出來單獨成爲一個測試階段。非功能性測試一般都包含有這些內容：可操作性（包括監控、日誌、審計/歷史記錄）、可靠性（包括故障轉移，單個組件故障，完整故障，接口故障）以及安全性。無論瀑布項目還是敏捷項目，在這個測試階段都會遇到重重阻礙，二者的差異不太突出。
非功能性測試應該考慮以下幾點：
1、非功能性需求一般都是很難捕獲的，而且即便被捕獲，也很難進行度量。（例如：99.9%的無故障時間）
2、儘可能讓所有的非功能測試都自動化執行，把它們也都放到系統集成測試環境中。
3、在定義測試用例的時候，讓真正要監控產品環境並對其提供支持的人也參與進來。
4、在應用程序成爲產品以後，非功能測試或監控還要繼續。
迴歸測試
在瀑布項目中，迴歸測試無論從時間上還是費用上來看，都算得上是成本最高的測試階段了。如果在項目晚期（如UAT階段）發現了缺陷，再構建應用程序的時候，就得把所有單元測試、功能測試和用戶驗收測試重新運行一遍。因爲大多數瀑布項目都沒有自動化測試，所以迴歸測試的開銷就很大。敏捷項目以持續構建和自動化測試來應對迴歸測試，使每次構建都可以進行迴歸測試。
迴歸測試應該考慮這一點：
每次迭代結束時都做一下手工測試，收集早期反饋。
產品校驗
產品校驗會在把產品交付給用戶使用之前，審查產品環境中的應用程序，看看所有內容是否否都已經正確安裝，系統的操作性如何。而有些測試還是隻能到了產品環境中才能完整運行的，最好儘快將其完成。無論是瀑布項目還是敏捷項目，產品校驗的方式並無二致。
產品校驗應該考慮以下幾點：
1、讓最終用戶來做產品校驗測試。
2、趁着產品系統還沒有正式上線，從這個測試階段的早期就要儘可能多地執行自動化迴歸測試。
瀑布項目和敏捷項目的測試階段還是很相似的，主要差異就是每個測試階段關注的重點和執行時機。敏捷項目中有大量的自動化測試，用持續集成來減少迴歸測試對項目帶來的影響。在瀑布項目中，如果發現應用程序的質量低下，那麼在晚期再去執行前期的測試就是很常見的事情（如在UAT的時候做功能測試）。敏捷項目可以減少測試中的浪費，在早期發現問題，讓團隊在交付應用時增強信心。
環境
在開發過程的各個階段都要用到測試環境，從而確保應用程序的正常運行。越到後期，測試環境與預期的產品環境就會越相似。測試環境一般都會包括一個開發環境，讓開發者集成代碼並運行一些測試。系統集成環境跟開發環境有些類似，不過它會集成更多的第三方應用程序，也許還有大批量的數據。試機環境幾乎是產品環境的鏡像，也是應用程序變成產品之前的最後一個階段。
敏捷項目和瀑布項目所需的環境沒太大區別，其中一個不同之處在於，敏捷項目從項目伊始直至項目結束，都要用到所有的環境。在敏捷項目中，保證所有的環境都一直正常工作也是很重要的。無論因爲什麼原因讓某個環境出現故障，都要立刻讓它重新工作起來。在這個話題上，敏捷和瀑布還有另外一點差異，那就是環境的計劃和資源分配對它們的影響不同，尤其是當各種環境被項目之外的團隊進行管理的時候，其差異尤爲顯著。
開發集成環境
開發者在開發環境中集成代碼，開發應用程序。瀑布項目對開發環境的重要性不會考慮太多；開發環境中的代碼一直都不能工作，到了開發者需要彼此集成代碼的時候纔想起來使用，而這時項目已經臨近尾聲。在敏捷項目中，開發環境是整個開發工作中不可分割的一部分，在開始編碼之前就必須準備就緒。這個環境會被用來持續地集成代碼和運行測試套件。無論因爲什麼原因造成環境故障，都要立刻修復。
開發環境應該考慮以下幾點：
1、集成代碼、構建和測試的時間加起來不要超過15分鐘。
2、每個開發人員所用的環境跟開發環境保持一致（硬件環境可以不一樣，但軟件環境一定要一樣）。
3、所用的數據要儘可能跟產品數據保持一致。如果產品數據過於寵大，難以載入，也可以只取一部分。在每個發佈週期的開始階段，這些數據要從產品數據中重新更新。
4、管理這個環境的責任應該落在項目團隊身上。
5、向這個環境中部署的頻率大約是以小時計算。
6、自動部署。
系統集成環境
系統集成環境用來將所開發的應用程序和其他應用程序進行集成。在瀑布項目中，這個環境只會在項目臨近尾聲的時候纔會用到，而且傾向於多個項目共用一個集成環境。在敏捷項目中，一旦開始編碼，這個環境就要準備就緒。應用程序會被頻繁部署到這個環境中，繼而開始執行功能測試、集成測試、可用性測試和探索性測試等等。應用程序的演示是在這個環境中進行。
系統集成環境應該考慮以下幾點。
1、集成點應該被真正的外部應用程序所代替。外部應用程序應該處於測試狀態，而非真正的生產版本。
2、把產品環境的架構複製過來。
3、把這個環境中所使用的數據應該是產品環境數據的副本，每個發佈週期的開始階段，都要從產品數據中重新更新。
4、建立運行這個環境中所有測試的系統集成持續構建。
5、管理這個環境的責任應該落在項目團隊身上。
6、向這個環境中部署構建的頻率大約是以天計算。
7、自動部署應用程序。
試機環境
試機環境用來驗證應用程序可以部署爲產品，而且工作正常。爲了達到這個目的，試機環境應該完全複製產品環境，包括網絡配置、路由器、交換機以及計算機性能等等。在瀑布項目中這個環境往往需要“預訂”也要有一個計劃，計劃在這個環境中進行多少次部署以及何時進行部署。敏捷項目對這個環境不像對開發環境和集成環境那樣依賴；不過在項目的整個生命週期中，還是需要常常進行部署。
試機環境應該考慮以下幾點：
1、這裏的數據應該是產品數據的完整副本，每次應用程序部署前都要更新。
2、用它來驗證UAT， 性能測試和非功能測試（穩定性、可靠性等等）
3、向這個環境中部署構建的頻率大約是以迭代計算，如每兩週一次。
4、管理這個環境的人應該就是管理產品環境的人，讓他提前接觸應用程序並進行知識傳遞。
5、自動部署應用程序。
產品環境
產品環境是應用程序正式上線時的環境。產品校驗測試就在這個環境中執行，同時會做一些度量以檢驗測試成果。瀑布項目和敏捷項目在這裏的區別不大。在敏捷項目中，發佈過程會盡力做到自動化，爲向產品環境中頻繁發佈提供條件。
產品環境應該考慮以下幾點：
1、在應用程序正式上線之前，在產品環境中做迴歸測試。
2、要做度量，以檢驗測試成果，例如在前三個月到六個月之前，用戶報告了多少問題，問題的嚴重性如何。
無論是哪種項目，要保證時間期限，就都得做到在需要用到環境的時候就有一個環境可供使用。瀑布項目會設法遵守嚴格的計劃，便於對環境做安排。敏捷項目的靈活性更強。也許有了足夠的功能就可以進入試機環境了，或者業務人員會決定產品提前上線。爲了做到向試機環境快速部署，然後進入產品環境，就要有系統集成環境以及有關過程的輔助。
問題管理
問題包括缺陷（bug）和變更請求。瀑布項目有着嚴格的缺陷和變更請求管理，而敏捷項目飽含變化，所以就沒有那麼嚴格的變更管理。如果需要有變更，就創建一個（或是一些）故事，放到待處理事項裏面。高優先級的故事會放到下一次迭代中完成。
缺陷管理在敏捷項目中依然適用。如果有人發現一個正在開發故事有缺陷，大家就會進行非正式的溝通，發現缺陷的人把它告訴開發人員，缺陷立刻被修復。如果某個缺陷並不屬於當前迭代中開發的故事，或者屬於當前故事，但並不嚴重，那就用缺陷跟蹤工具記錄下來。這個缺陷會被當做故事處理；也就是說，會創建一張故事卡，讓客戶排優先級，放待處理故事裏面。團隊需要進行權衡：要找問題所在，爲大家理解這個問題並安排優先級提供足夠的信息，但又不能在一個對客戶而言優先級並不是很高的缺陷上面花太多時間。
瀑布項目和敏捷項目的缺陷內容（描述、組件、嚴重程序等）是一樣的，除了一個字段以外：敏捷項目多了一個字段- 業務價值，如果可能的話就用幣值描述。這個字段表示如果缺陷被解決的話可以帶來多少業務價值。將業務價值跟缺陷關聯以後，客戶就更好地判斷這個缺陷跟新功能相比是不是更有價值，是不是應該有更高的優先級。
工具
所有項目都要用到工具，只是程序不同。瀑布項目用工具來強化過程以及提高效率，這有時會造成衝突。敏捷項目用工具輔助提升效率，與過程無關。在敏捷項目中，所有的測試都應該可以在任何團隊成員的個人環境中運行，也就是說，所有人都可以使用那些自動化測試用例的工具。所以敏捷項目中會經常用到開源產品，這又意味着使用這些工具需要不同的技能。開源工具不像商業工具那樣有齊備的文檔和完善的支持，用這些工具的人要有很強的編碼能力。如果有人編程能力偏弱，就可以通過跟人結對來提升個人技能。在敏捷項目中也可以使用商業工具，但是大多數商業工具在開發的時候都沒有考慮敏捷過程，所以敏捷項目匹配起來就不太容易。而且要讓商業工具跟持續集成配合，可能要寫很多代碼才行。
項目中應該考慮爲下面一些測試任務使用工具
1、持續集成（如CruiseControl， Tinderbox）
2、單元測試（如JUnit， NUnit）
3、代碼覆蓋率率（如Clover， PureCoverage）
4、功能測試（如：HttpUnit， Selenium， Quick Test professional）
5、用戶驗收測試（如：Fitness， Quick Test Professional）
6、性能測試（如：JMeter， LoadRunner）
7、問題跟蹤（如：BugZilla， JIRA）
8、測試管理（如：Quality Center）
報表與度量
度量數據是用來衡量軟件質量和測試成果的。在瀑布項目中，有些測試度量指標需要在測試之前就把所有測試用例都寫好，而且僅在應用程序開發完畢時進行一次測試。這種指標包括：每個測試用例執行的時候發現多少缺陷，每天執行的測試用例會發現多少缺陷。這些度量數據收集起來以後，便用來判斷應用程序是否已經就緒並可以發佈。在敏捷項目中，功能完成的時候測試用例就已經寫好且運行完畢，這就意味着用來度量瀑布項目的一些指標是無法應用在這上面的。
回到收集度量數據的原因上來-衡量軟件質量和測試成果，你可以看看下面這些概念。
1、用代碼覆蓋率度量測試效果；這對於單元測試尤其有效。
2、在探索性測試階段發現的缺陷數量可以說明單元測試和功能測試的效果。
3、在UAT階段發現的缺陷表示先期的測試並不像UAT一樣充分，我們應該關注業務過程， 而不是軟件的bug。如果UAT發現了很多功能性問題，而不是軟件的bug，這就表示團隊對故事或是變化的需求理解不足。
4、故事完成以後所發現的缺陷數量能夠作爲衡量軟件質量的好手段。這些缺陷包括在集成測試、非功能測試、性能測試和UAT測試中發現的缺陷。
5、缺陷重現率。如果缺陷常常重現，軟件質量就很低。
測試角色
測試角色並不是跟單個資源一一對應的。一個資源可以擔任多個測試角色，一個測試角色也可以由多個資源負責。下面列出的這些角色是確保項目測試效果所必需的。一個優秀的測試人員應該具備所有這些角色的特徵。敏捷項目和瀑布項目都有這些角色，只是扮演這些角色的人不同。在敏捷項目中，所有團隊成員都是怎麼扮演各個角色的。這並不是強制性的規定；每個團隊各有差異，不過這種做法也算得上是不錯的組合。
測試分析人員要了解需求、架構、代碼等各個產物，從而判斷哪些需要做測試，哪些是測試要重點關注的地方。
在瀑布項目中一般是有一個（或多個）資深的資源來擔任這個角色。他們檢查相關文檔（需求、設計、架構），編寫測試計劃、編寫高層的測試用例描述，然後把所有的東西都交給一個初級員工，讓他填補詳細的測試腳本。敏捷項目鼓勵所有團隊成員一起擔任這個角色。開發人員的關注點是通過分析代碼和設計來編寫單元測試，但是他們也會協助業務分析師或者測試人員編寫功能測試，還會參與非功能測試和性能測試的分析。業務分析師和測試人員緊密協作，編寫功能測試和用戶驗收測試，並執行探索性測試。客戶/最終用戶會被邀請參與用戶驗收測試。
測試腳本編寫員
該角色就是編寫詳細測試腳本的人。這些腳本可能供手工執行，也可能被自動化。瀑布項目中的腳本編寫就是個初級員工，他根據測試計劃和測試用例描述來編寫手冊，每一步都描述的很詳盡、自動化腳本編寫員就得是更資深的人了，開發人員也會參與單元測試用例的編寫。敏捷項目會大量使用開發人員來編寫測試腳本，主要是因爲測試腳本是自動化執行的。
測試執行員
不管是手工測試還是自動化測試都有這個角色，不過在自動化的時候，這個角色的扮演者就是一臺電腦。測試執行員會執行詳細測試腳本，判斷哪些測試失敗，哪些測試通過。瀑布項目一般都用測試人員來做這件事情，而敏捷項目則鼓勵所有人都來參與，尤其是測試人員、業務分析量和客戶。
環境管理人員
這個角色管理測試環境，包括應用程序運行的環境以及支持自動化測試的基礎架構。他們還會關注外部接口和用作測試的數據。這個角色在瀑布項目和敏捷項目中很相似。
問題管理人員
問題出現以後就要解決。這個角色可以幫助篩查問題，確保它們被正確地創建，有各種屬性，如嚴重程度、優先級、組件等等。這個角色還要管理問題的生命週期，並提供工具支持。這個角色在瀑布項目和敏捷項目中很相似。
故障檢測人員
這個角色當問題出現的時候就要去做故障檢測工作，判斷是不是軟件缺陷。如果是軟件缺陷，他們就要去找出問題根源、可能的解決方案和變通措施。這個角色在瀑布項目和敏捷項目中很相似。
敏捷團隊所注重的是讓各個角色得到充分發揮，而比較少關心誰在做什麼事情、誰對哪些事情負責。測試人員和其他團隊成員之間沒有界限，他們共同的目標是生產出更高質量的軟件，每個成員都要盡一切可能幫助達成這個目標。在敏捷團隊中，測試人員可以從所有人那裏得到幫助，而他們又可以幫助其他人提高測試技能。這種方式能夠確保團隊中的每個人都在爲交付高質量應用程序而付出。