敏捷測試的方法與實踐

前言

如果您已經閱讀過敏捷測試系列文章的第一篇，敏捷的實質，您應該已經瞭解敏捷的定義，瞭解什麼樣的團隊是敏捷的團隊了。而您也可能早已開始思考，什麼是敏捷測試的實質？敏捷的測試團隊又是如何形成自我管理、自我發展的組織呢？測試團隊又是如何安排日常工作呢？敏捷測試活動與傳統測試活動有很大差異嗎？為了進一步讓您瞭解如何將敏捷原則運用到活生生的日常測試活動中，我們為您推薦敏捷測試系列文章的第二篇——敏捷測試的實踐。

在敏捷活動如火如荼的推廣運動中，我們顯然無法預知如何在您的特定的複雜環境中您能否最後達成所願，也無法為您預測出前進道路的分岔口可能唯一的正確的線路，我們卻可以為您點起一盞明亮“街燈”，在這迷霧中驅除黑暗。我們將為您提供一個可以借鑑和可供參考的成功的敏捷測試實踐案例。我們將逐一向您介紹、分析這個案例中的敏捷團隊的組織結構，主要的敏捷測試行為，迭代的測試模型和一套以四周為週期的敏捷測試活動時間表。

請您運用您已具備的敏捷實質、敏捷原則的知識，並結合您的獨特專案環境、帶著您的問題，與筆者一起再度分析這個案例，希望您最終也能得到滿意的答案，並隨後開始實施部署敏捷測試。

敏捷測試的實質

測試不僅僅是測試軟體本身，還包括軟體測試的過程和模式。產品釋出後才發現很多問題，很可能是軟體開發過程出了問題。因此測試除了需要確保軟體的質量，即軟體做了正確的事情，以及軟體做了應該做的事情以外，敏捷的測試團隊還要保證整個軟體開發過程是正確的。

敏捷開發的最大特點是高度迭代，有周期性，並且能夠及時、持續的響應客戶的頻繁反饋。敏捷測試即是不斷修正質量指標，正確建立測試策略，確認客戶的有效需求得以圓滿實現和確保整個生產的過程安全的、及時的釋出最終產品。敏捷測試人員因而需要在活動中關注產品需求，產品設計，解讀原始碼；在獨立完成各項測試計劃、測試執行工作的同時，敏捷測試人員需要參與幾乎所有的團隊討論，團隊決策。作為一名優秀的敏捷測試人員，他（她）需要在有限的時間內完成更多的測試的準備和執行，並富有極強的責任心和領導力。更重要的是，優秀的測試人員需要能夠擴充套件開來做更多的與測試或許無關，但與團隊共同目標直接相關的工作。他（她）將幫助團隊其他成員解決困難、幫助實現其預期目標，發揚高度協作精神以幫助團隊的最終獲取成功。需要指出的是，團隊的高度協作既需要團隊成員的勇敢，更需要團隊成員的主動配合和幫助。對於測試人員如此，對於開發、設計人員，其他成員也是如此。

敏捷測試的方法與實踐

是的，敏捷測試也需要高度迭代工作、頻繁得到 STAKEHOLDER、客戶的反饋，需要動態調整測試計劃、測試的執行。並且，敏捷測試人員參與到了更多的敏捷生產活動中，積極的影響了團隊做出的決定和計劃。

是的，“人”才是敏捷的實體，敏捷測試也是以人為本的。不難理解，“敏捷”的一切都圍繞著人展開，如敏捷鼓勵直接，平行的溝通；敏捷需要持續的客戶反饋以及敏捷活動的設計，方案和決策需要團隊協同制定等等，敏捷測試需要一支非同尋常的團隊，不同於以往傳統開發模式下的團隊結構。關於敏捷團隊、敏捷測試團隊的組成和介紹，將是我們講述敏捷測試實踐的第一步。

“人”是重心，方法、策略是輔。為了適應不同的團隊結構，不同的專案環境，敏捷專案和敏捷活動的實踐也應該因“人”而異，但是，並不是說可以天馬行空，我行我素。一旦脫離了正確的敏捷方法、和敏捷原則的指導，我們的敏捷活動就好比摸黑前行了。

這正是我們需要學習前輩和敏捷主義大師們的經驗意義所在了，筆者在過去的實踐中受益頗多的也正是前人的實踐經驗和方法。因此，學習前人的經驗和方法，並運用這些最佳實踐來幫助敏捷開發團隊，甚至是傳統團隊來解決時下重要的問題是十分有意義的事情。筆者不敢妄自尊大將自己的一般實踐納入經典方法範疇，但經歷了兩年的研究和改進，筆者提出的敏捷測試的原則也得到了業內同僚和“大師”的普遍認可。經過多次和其他專案團隊的經驗交流，我們也不斷的改進著我們的原則、方法。因此，筆者要非常感謝參與討論的同僚們，沒有你們的熱情參與，也不會有今天的筆者信心百倍的執筆了。正如筆者在借鑑了前人的成功案例中的經驗和方法之後定製了符合專案需求的測試原則一樣，相信，讀者們在閱讀了筆者的敏捷測試原則和方法後，同樣也會有所收穫。而對筆者經歷的敏捷實踐活動中的方法和測試模型的講解將成為我們講述敏捷實踐的第二步，也是本文的重點。

綜上所述，筆者將運用本文的主要篇幅為大家講解這個敏捷實踐。它們是：

1. 敏捷團隊組織構成，敏捷測試團隊的任務和使命；
2. 敏捷開發團隊以測試為驅動的開發方式——測試驅動開發，這是種獨特的測試？還是開發？
3. 遞增型的迭代測試，它首先是對敏捷測試過程活動和生命週期模型的介紹，通過學習經典的敏捷增量測試模型，我們將敏捷測試的各類活動有機的組合到了一起。在此之上，對定製後的獨特敏捷增量測試模型的分析和理解，幫助我們理解測試活動的規劃和管理；
4. 以及需要特別關注的遞增型迭代測試的關鍵活動之一——“靜態測試”；這也是筆者認為的最高難度、最具影響力的敏捷測試活動。它將測試團隊最早的引入產品開發環節，測試人員以第一使用者的角度判斷設計的有效性，此活動較早的暴露了設計缺陷、避免了團隊對目標的不一致理解等，是測試活動中最有創造性價值的部分；
5. 最後，筆者將談談測試活動中的測試計劃和管理，即關於測試任務估計，測試活動計劃，各個重要測試活動時間分配與安排的介紹。

然而，敏捷測試不是一蹴而就的，做到真正的敏捷，無論是從傳統測試模式向敏捷測試的過渡，還是組建全新的團隊都是需要循序漸進的，同時也需要團隊成員的通力合作和不斷的實踐來完善敏捷測試的實踐原則和方法。

敏捷團隊

考慮到敏捷團隊的組織結構，讓我們以筆者親身經歷的專案為例來說明。筆者曾共事的整支產品開發團隊被劃分成 4 個相對獨立的敏捷開發隊伍，而每支隊伍擁有相同配置的 7 名成員，他們分別具有不同的職能屬性。如圖 1 所示，每支敏捷隊伍組成成員角色包括 1 名 UCD（User Centered Designer），主要負責產品的主要設計，其工作主要包括介面設計、使用者的用例設計等等； 1 名 Visual Designer，主要負責產品介面的色彩搭配、控制元件的外觀設計和 UCD 介面設計方案的初步實現和美化；1 名 Information Developer，主要負責產品中資訊的編輯和重要文件的撰寫工作； 3 名開發人員，主要負責產品的實現。和 1 名 QA，主要負責產品質量的保障。（更多的我們將 QA 定義為具有相比於測試人員擁有更多責任的一個職能，在本文中，為了簡便起見，我們仍稱之測試人員）。4 支敏捷的隊伍擁有相同的 SCRUM MASTER STAKEHOLDER。通常會在同一時間進入一個迭代週期，制定各自的敏捷計劃，並在同一時間退出，釋出各自功能實現。而 4 支隊伍的勞動果實被整合到一起就形成了可釋出的產品了。

圖 1. 敏捷開發團隊的組織結構

因為敏捷團隊中只有 1 名測試人員，因此需要一臂承擔測試策略的制定，測試計劃，測試指令碼，測試用例設計以及測試的執行，幫助團隊發現潛在問題，並協助解決問題的工作。敏捷團隊的敏捷原則也是測試人員敏捷活動的規範，測試也需要擁有和團隊的良好溝通，高度迭代的活動和不斷的獲得 STAKEHOLDER 的反饋。那團隊的結構與敏捷本身有什麼直接關係呢？與敏捷測試又有多少關聯呢？

談到這裡，想起曾經有朋友向我諮詢有關敏捷團隊的某些職能的人力配備的問題。其實，筆者也無意論證 7 個人為什麼是最佳組合，為什麼不是 17 個，20 個人的組合。但是，敏捷原則告訴我們敏捷團隊是高度協同、民主和平等的團隊，為了讓團隊中每個人充分高效的工作。相同職能下的組員至多不好超過 3 名，最佳配置也是不同職能下配置 1 個人頭。因此、在這樣一個小型、平行的組織結構裡，溝通更加易於建立，溝通複雜度也相對較低，相比 17、20 人的團隊組織，溝通的代價也小很多。相反，很難想象在一個敏捷團隊中會擁有諸多不同風格的執行者，決策者將是個怎樣的混亂情況。

此外，經歷過敏捷測試的體驗，我們發現一個單一的敏捷團隊最好保持較小的“尺寸”。這是因為擁有很多測試人員的敏捷團隊通常不但需要更大的實際工作量來匹配龐大的機體而導致團隊任務量更巨大，更復雜，失去自我管理的信心，而每個測試人員也將要花費大量精力和時間投入到內部溝通，和可能因為內部缺乏一致而導致的更加頻繁的反覆溝通中。

每名敏捷的測試人員需要和其他敏捷團隊成員保持頻繁而必要的溝通以保證對目標，需求、設計的充分正確的理解，對需求變化能夠迅速的做出反應。另外，還需要與職能隊伍中的其他測試成員保持一致性。如此一來，溝通代價激增了，它將佔到測試人員的工作中的較大比例。而這種內部溝通、協調，卻不能定義為敏捷的 Backlog 專案來計入團隊整體的工作輸出。因此，整體的測試效率並不一定隨著人力資源的投入而遞增。非但沒有實現敏捷原則，而恐怕因為團隊的組織結構變得更加龐雜。所謂的“自我管理、自我發展”的團隊只能因而依靠傳統的管理和規劃了。筆者認為，除了因為特殊階段，特殊時期，敏捷團隊需要“聚合”更多資源來一併解決存在的高優先順序的體力型問題外，敏捷的團隊應該儘量保持著較小的“尺寸”。

果真專案投入了很多的人力資源，無論設計還是實現、測試團隊擁有較大的人數，那麼我們應該考慮將這樣的團隊可以分得更小些，工作量也相應分得更精細些，直至接近我們建議的最佳組合。至少我們認為要做好敏捷測試，就要確保敏捷團隊中的每一個職能擁有足夠清晰的職責範圍和一定程度下自由空間和在這個空間內的充分授權。因此，但從人數和職能構成上，敏捷團隊的構成一定是不可忽略的重點。

正像我們前面提到的，確認軟體開發過程的正確性也尤為重要，因此作為敏捷的測試人員，更要了解敏捷的過程，比如說，測試人員需要幫助 UCD 和開發人員確定需求的可行性，測試人員要督促開發人員及時釋出 build，以保障迭代結果最終能夠在通過足夠的測試後成功釋出等。在 build 釋出後，測試人員要首先驗證當前迭代的任務是否已經完成，其次才是驗證產品功能的正確性。也為了能夠在日後重複性和體力型勞動中解放出寶貴的時間去覆蓋測試更加緊要的內容，如可用性，全球化等，測試人員需要自動化一部分測試，創新的、靈活的工作。

敏捷團隊是自我管理的團隊，高度協作的團隊，質量目標即是測試團隊也是整個開發團隊追求的目標，因此開發團隊應將做好單元測試，設計團隊將幫助測試團隊設計好測試用例作為計劃內的一項工作。這裡我們推廣、建議開發人員採用、普及測試驅動開發模式。

測試驅動開發

測試驅動開發表現出迭代開發的最核心的就是開發人員自己能夠第一時間確認其需求得到了正確實現，而當單元測試覆蓋了更多的內容，程式碼質量也將得到提高。測試驅動開發的指導思想就是讓開發人員在編寫功能程式碼之前，先根據需求編寫測試程式碼。先思考如何對將要實現的功能進行驗證，並完成單元測試指令碼的編寫，然後編寫足夠，僅僅足夠的功能程式碼滿足這些測試用例，直至通過測試。按照這個方法，遞增的在迭代中增加新功能的單元測試和功能程式碼編寫，直到完成全部功能的開發。

在單元測試活動中，測試人員也被鼓勵參與到單元測試的設計中來，不但可以幫助開發人員構思出更多的單元測試用例來擴大單元測試的覆蓋率，還可通過學習如何使用單元測試，如何複用單元測試用例到迴歸測試和功能測試，以達到最大化利用有效的資源（如下圖）和節約成本的作用。同時，在迴歸測試和使用者接收測試（User Acceptance Test）中如能將單元測試指令碼有機的關聯起來，並自動化其執行，更能夠進一步提高測試的成效並降低測試成本。

單元測試指令碼因隨需求、設計的變化隨時更新。需要開發人員站在全域性的立場，開發始終堅持先修改測試指令碼，再修改產品原始碼。此時，也建議測試人員參與單元測試指令碼的改進，幫助開發人員合理的變更單元測試指令碼，同時著手修改測試計劃和測試策略。

圖 2. 測試驅動開發
 

遞增的迭代測試

測試驅動開發的原則應該運用於每一迭代週期的開發中。但是，測試驅動開發的單元測試仍然是以開發為目的的活動，雖然自動化測試，迴歸測試和使用者的接收測試（User Acceptance Test）可以通過複用單元測試指令碼提高以後的測試工作的效率，但單元測試不是我們敏捷測試討論的重點。

敏捷測試活動的主要承載者還是敏捷測試人員。測試人員如何運用敏捷原則指導測試活動還是筆者在敏捷測試實踐一文中要講述的重點。以下，筆者將通過兩個迭代測試模型來幫助瞭解測試人員如何結合敏捷原則實踐敏捷的測試活動。

經典敏捷增量測試模型

測試是敏捷開發過程重要的環節，自始自終測試貫穿於每個迭代。Scott W. Ambler 認為就整個產品的敏捷開發生命週期可以分為 4 個階段，即初始階段，專案的建設階段，產品釋出階段和產品的維護階段，在關鍵的專案建設階段中，測試被分成兩個部分，Confirmatory 測試和 Investigative 測試。 ¹ 下面，我們來講講迭代的測試的這兩個方面。

圖 3. 敏捷測試生命週期

Confirmative 測試就是對 build 的有效性和關鍵的功能是否正確進行驗證，測試人員依據測試用例和測試指令碼的完整測試是工作的重心。原文中的 Confirmative 測試包含了開發人員的單元測試（必不可少的重要開發活動）和被稱之為 Agile Acceptance Testing 的測試部分，這段時間的測試任務用來保障迭代的必須輸出的質量。基本的功能、非功能的任務，但凡是在迭代開始時制定的計劃中承諾的高優先順序需求，哪怕是很繁瑣的細節工作都要被充分的測試和驗證。

Investigative 測試是對 Confirmative 測試的補充和是更廣泛的測試活動，測試團隊在完成 Confirmative 測試後的時間用來做這部分測試，它包含功能測試，文件測試和系統測試以及和其他產品、環境之間產生的必然的 Integration 測試，還有個非常有趣的測試活動叫做 Exploratory 測試，筆者認為這部分測試是測試人員創造性的採用多種不同途徑去嘗試測試產品。就好比“猴子敲鍵盤”一樣，測試員使用各種手段來考驗 build 和產品的穩定和正確性等。

圖 4. 敏捷測試的 Incremental Testing

自定製的敏捷增量測試模型

我們在敏捷專案開發的過程中使用了定製的測試流程，我們同樣有相同的兩部分測試，即 Confirmative 和 Investigative 兩部分。不同的是，我們原則的將這兩部分測試都放在當前迭代的計劃內完成。原因是，敏捷測試團隊針對當前迭代的任務計劃本應服務於當前的產品，過去的迭代產物，或者因為需求變更不再適用，又或者因為未解決的質量缺陷使得實際測試效果不佳。而同時，因為 Product Owner 和 STAKEHOLDER 的期望是團隊能夠高效的完成當前迭代的任務，完成更高優先順序的工作，每個迭代的考核亦非常清晰。為了完成服從當前的高優先順序任務，計劃，也為了 STAKEHOLDER 更好的關注和幫助當前問題的及時解決，測試人員對以往 Build 的測試應應合理的計入先前迭代的任務而不是當前迭代計劃。倘若真要測試以往的產品而不是最新的，敏捷測試的管理也將變得有些困難，同時測試團隊所關注的問題也只能是過時的，只能成為團隊的低優先順序的問題。這不是與團隊整體的目標背離嗎？因此，我們建議測試團隊使用我們改進後的敏捷增量測試模型，即在當前迭代僅僅完成當前迭代的計劃，而所有測試都需要圍繞最新的產品 Build 進行。

圖 5. 定製的 Incremental Testing

在我們新的增量測試模型中 Confirmative 測試包含對需求的靜態測試，開發人員做的單元測試，以及 Build 驗證測試，功能測試（僅限於對當前迭代功能）和重要的其他型別測試。通過了 Confirmative 測試的產品 Build 就可以作為在迭代結束時釋出了。而為了產品擁有更好的質量，也為了完成對那些較低優先順序的質量驗證的需求得以確保成功的實現，我們需要針對性的做系統測試，壓力，併發，安全甚至全球化的測試，這部分我們把它叫做 Investigative 測試。還需要強調的是，為了保障產品的最終穩定，為了產品不會出現在程式碼重構後的質量回歸現象，我們將回歸測試（Regression Test）放在這個階段，用以涵蓋對以往關鍵功能的再度驗證。

靜態測試

在筆者的測試模型裡，confirmative 測試增加了“靜態測試”，本人認為這部分測試是對測試人員最具挑戰的部分。一個好的測試人員能夠第一時間找到需求分析、設計中的模稜兩可，遺漏，錯誤的地方，能夠促進團隊前期工作的高效完成，將很大程度降低將來產品的質量缺陷的數量，積極影響了敏捷開發的最終輸出。這部分工作是測試團隊，開發、設計團隊最默契合作的階段，交流非常頻繁，正是通過積極的溝通和及時的修正與團隊目標“誤差”使得團隊更加明確其方向，更有凝聚力和也得以發揮了團隊的最佳戰鬥力。在筆者的專案經歷中，往往這個階段會需要一個迭代週期 1/4 左右的時間。這同時也說明了靜態測試在敏捷測試型別中的重要性。

在敏捷開發過程的靜態測試即專案迭代開發前期測試人員的最主要工作。值得再次強調的是，在這段時期測試人員的工作重心是認真瞭解需求和用例設計，並針對設計的可行性，可用性進行驗證，確認設計是對需求的準確實現，最佳實現。

圖 6. 靜態測試需要的 Strategy Thinking

對於靜態測試的方法，我們在這裡需要推廣 RUP 的 Use Case，這是個很好的分析需求的方法，也是測試人員作為靜態測試的使用的方法之一。對產品長期戰略和業務的熟悉可以幫助測試人員更好的理解團隊的用例設計，檢視、模組等，也能夠通過對比分析，直接找出某些設計中的缺陷，以提高設計的質量。專案的開發前期階段，設計是佔有非常重要的比例，而設計是直接影響產品質量的環節，因而確保這一階段的質量對產品的品質提高起到決定性作用。針對開發出來的用例，設計者對用例的描述通常故事情節比較簡單，缺乏完備和邏輯的縝密。而開發和測試需要的是詳細的設計，這個用例設計和各種輔助的邏輯應該將用例定義的清晰和明確，例如邊界條件，例外條件，資料的格式和其他效能指標的界定等等都需要涵蓋。因此，測試人員應該領導團隊幫助明確出用例更多的細節。比如，在一次設計用例討論中，設計者提出“我需要一個 Overlayer”。那麼測試人員應該要問：“如何開啟這樣一個 Overlayer，如何關閉？”“這個 Overlayer 需要多大平面尺寸，是否支援調整，是否支援對螢幕大小的自動適應”，“Overlayer 的開啟和關閉是否需要有動態漸變的效果？”，“Overlayer 的是否需要滾動條？”，等等。

這個過程能夠幫助團隊發現早期的設計缺陷，通過發現問題，並定製新的設計方案，團隊也通過這個過程，更好的瞭解了測試的重要性，也摒除了可能存在的對需求的種種“假設”，因而更加明確了團隊的目標和方向。這是個非常關鍵的過程。尤其是對測試人員而言，任何“假設“都是有害的，所以一定需要把不清楚和模稜兩可的問題從一開始就理清楚。

敏捷測試的計劃與管理

做好了測試的思想準備，並瞭解如何從需求開發出測試用例，敏捷測試人員接著需要做的就是參考產品需求和團隊的設計制定和計劃測試任務和各種測試活動，即測試策略和測試計劃的制定。每個迭代敏捷開發都將關係產品的功能點和非功能點的需求作為產品的 Backlog 編入待開發的序列，敏捷團隊從中會選擇適量的 Backlog 專案來作為當前迭代的 Backlog 去實現。測試人員同樣根據需要制定出相應的測試工作，並羅列於團隊的 Backlog 專案中，承諾了在迭代結束時可以做好的足夠的測試工作。

對於測試計劃中的 confirmative 測試，這部分必須做到高質量的按時完成。而對於 Investigative 部分，我們應該適量的計劃到當前迭代中，切忌不要做 over commit。

圖 7. 計劃測試 Backlog 專案

接著，測試人員需要撰寫測試用例和測試指令碼了。測試用例的撰寫和傳統測試基本沒什麼差異，按照已有的模式撰寫就好了。筆者的測試團隊，使用了 XML 檔案格式儲存所有測試用例，原因主要是沿用了測試團隊原有的習慣，而同時也因為 XML 測試用例能夠更好的匹配自動化測試的需要，並且便於更新。測試指令碼是自動化測試的產物，敏捷開發週期短，變化多，很難拿到一個穩定的產品再開始做自動化。而自動化指令碼的設計自然要避免去測試不穩定部分，開始的迭代週期幾乎百廢待興，自動化作用不大，到了中期，筆者的團隊自動化測試才稍成氣候。

測試人員需要的是在根據測試策略開發出這相應指令碼和用例，需要把握測試範圍，與計劃和測試策略一致，測試也要量力而行，做到足夠的測試，保障迭代的正常退出就很好了。

圖 8. 依據 Business Scenario 制定測試策略

敏捷測試的活動時間表

通過實施上述的敏捷測試原則，測試團隊可以逐漸形成符合自身特點的敏捷測試流程、敏捷測試最佳實踐，久而久之形成獨立的敏捷團隊文化。以筆者所在團隊為例，歷時 1 年，經歷 12 個迭代後，我們逐漸形成了一套可以遵循測試活動時間表。我將他放到文章的最後，這張表包含了敏捷測試團隊的各項活動安排和必要的前提與進入條件。在這張表中，測試團隊較早的涉入，較早的開展測試，以及各項相關工作，並與設計和開發人員緊密的合作，它確保了測試團隊乃至整個敏捷團隊的工作的按期完成，是值得向大家推薦一種最佳實踐。因為篇幅關係，這裡僅對其做簡單的描述。

圖 9. 敏捷測試 Work Flow 最佳實踐

第一週的工作如先前所講，做靜態測試，確定測試策略和制定可行的測試計劃，劃定測試範圍。這個階段的前提是敏捷團隊確定了當下迭代週期內需要完成的 Backlog 專案。

第二週的工作是準備開始測試的執行，因此要準備好測試用例和測試環境。特別的是，測試人員是根據需求和團隊討論、設計出的用例來開發測試用例的。雖然測試用例的細節程度不能與傳統開發中針對已經開發完的產品、產品開發文件開發的測試用例相比，相反，許多細節，尤其是還未由團隊最終確定的內容仍是待定狀態；但是，這些細節並非影響測試的用例設計，相反它不但簡潔、易懂，也擁有很好的靈活度，它能夠實時響應各種變化。而且，測試用例記錄了大量的待定部分，它時刻在測試人員的腦中，測試人員用這種方式簡單的告知團隊，我們還有未完成的設計和未定的方案，測試用例幫助團隊對產品的理解同步於此。

第三週的第三天，第一個可以執行的 Build 已經能夠釋出了（這個前提需要開發人員的密切配合）我們開始功能測試了。到第三週週末，一部分功能測試已經完成，大部分關鍵功能得到驗證。

第四周我們要結束測試，包括 Confirmative 的測試部分和 Investigative 的測試。在迭代驗收之前團隊要通力合作解決各種能夠解決的問題，保障 Backlog 的如期完成。這裡有一個問題值得再次提出來和大家討論，或許曾在敏捷專案中的許多人也都遇到了，那就是出現了一些質量缺陷沒有來得及在迭代退出前完全解決的現象。那是不是說明測試不能夠退出呢？筆者的回答是“不”。迭代的驗收時間即是迭代退出時間，也是測試團隊必須退出的時間。在實施中，我們將這些來不及解決的質量缺陷分成三類，一類是“希望能夠解決”的質量缺陷，這部分未解決質量缺陷將要成為新一輪迭代的“將做事宜”，甚至可能作為新一輪迭代的需求做到 Backlog 裡。第二部分是“必須解決”，這部分因為直接關係到最基本，最關鍵的功能，這樣的質量缺陷必須被立刻解決，否則就必須承認本次迭代的失敗了。第三部分是“不再重要的” 質量缺陷，這部分質量缺陷可以因為技術的不可實現，對客戶產生較小的影響或者考慮到不久因為程式碼重構，這樣的問題不在存在的理由，經過團隊和 STAKEHOLDER 的批准可以置成“推遲解決”，待日後解決或者定義到產品的版本說明文件中。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-408757/，如需轉載，請註明出處，否則將追究法律責任。