在測試工程師的世界裡，Defect 像是勳章、獎狀，是在無數個版本裡殺進殺出後取得的輝煌功績。而 Defect Tracking System 是展示區，各種大大小小的問題都被陳列在這裡，供團隊追溯與回憶。
但東西放久了會生灰塵，Defect 放久了則會出現 破窗效應，於是展示區成了高亮區，團隊成員開始踢皮球或是無視這些 Defect，如何管理好 Defect 成了個難題。
在敏捷軟體開發模式裡，我們將大型功能切分成數個小功能並透過迭代 (Iteration/Sprint) 的方式來進行開發工作，而每個迭代理會挑選數個 User Story 來進行。
但運作上我們很容易的就變成 Mini Waterfall:
Mini Waterfall 繼承了其原生的缺點: 回饋不夠即時、重工、開發測試團隊間易形成對立。
在這樣的運作模式裡，這些被認定已經開發完成的 Story 在進入到測試階段後，可能會被發現這裡有個 Defect 那裡遺漏了些規格，於是開發與測試間展開了一場對峙，Solution 與 Defect 成了乒乓球，一來一往的傳遞著。時間成了仲裁者，無法被即時修正的問題普遍的作法就是延後，日積月累形成大量的已知 Defect。
開發與測試應該是一體的
開發與測試是密不可分的，他們彼此手拉著手共同前進，開發程式時我們會寫一些程式，做一些測試再寫一些程式，直到程式完成為止。那為什麼在專案的測試上，要將測試視為一個獨立的里程碑 ?
開始移除迭代裡的測試里程碑吧！將測試視為開發工作的一部分，同時避免同時進行多個 Story，它除了增加工作管理上的困擾外，並不會提高團隊整體的生產力。
這樣的改變可以讓團隊從開發優先的思維轉變為修正優先。
- 開發優先: 優先完成開發，再進行測試。
- 修正優先: 暫緩開發工作，先優先修正問題，再繼續後續的開發。
兩種思維看似差異不大，對於團隊的工作文化卻有劇烈的影響。開發優先意味著 Defect 會先被擱置，待開發工作完成後，再依據其重要性來依序修正，而那些低優先順序的 Defect 往往會因為時程因素而被擱置。
這會逐漸形成一種壞味道，在幾個迭代後，那些無法被即時修正的問題，會從個位數蔓延至十位數、百位數，團隊也開始忽視這些被擱置的 Defect，因為多一個不多，少一個不少，在這種情況下很難有人可以持續保持對於 Defect 的正面態度。最終這些 Defect 累積成龐大的清單，無法消化也難以被管理。
Zero-Defects
讓這些食之無味，棄之可惜的 Defect 當作有機肥料任其自然淘汰是種做法，但採取優先修正的策略可以更積極的面對問題與確保主導權。
優先修正的概念又稱為 Zero-Defects，於 1964 被正式提出，更早的概念則可以追溯至二次世界大戰期間。
這樣做有幾個可能的好處:
- 工作目標一致，減少在不同 Story 間切換造成的 Context Switch 浪費。
- 減少 Undone 數量，一個確實完成的 Story 好過有兩個完成 50% 的 Story。
- 減少 Defect 庫存，更易於管理與聚焦在那些真正重要的事物上。
- 工作文化上的改變，團隊對於擱置 Defect 的容忍度會變低，自我要求變高。
要跨出這第一步，可以從重新建立對於 Defect 優先權的共識開始，簡單易於遵守的規則有助於團隊理解與遵守：
- 立即修正: 停止開發工作，立即修正該 Defect。
- 稍後修正: 可以延至下一個迭代再修正，視為一個 Improvement User Story。
- 有空再修正: 庫存起來當 Product Backlog，每 2 個迭代重新排序或刪除它。
Defect 會導致團隊生產力下降
Defect 是衡量軟體品質的關鍵指標，欠佳的品質會造成團隊必須反覆地執行測試與修正，而這每一次的往返都會剝落團隊的生產力，採取 Zero-Defects 的策略，減少 Defect 的庫存可以從今天就開始做起。
科科和測試 