http://www.zdnet.com.tw/enterprise/column/Prudentman/0,2003032119,20146502,00.htm
通達人
筆者在《SQA怎麼做的實戰教學》一文中介紹了SQA的一系列活動，也在《軟體開發專案 最怕錯估情勢》中介紹了「已病」和「 未病」的概念。 在這篇文章中，筆者將進一步介紹融合「已病」觀念的Defect管理手法。 Bug和Defect
在一般狀況下，Bug和Defect是指同一件事，也就是指軟體出現不符合預期結果的狀態。但在這篇文章中，Bug仍維持原來的意義，但Defect則隱含了Root Cause的元素，而不再只是Bug的表面徵狀如此簡單。
在實務上，同一徵狀的Bug，其產生原因可能不盡相同；但同一產生原因所產生的徵狀，也可能不全然相同。是否能被歸類在同一個Defect Pattern內，必須以Root Cause才能判定。
形成Pattern的主要條件
Bug要形成規律，首要條件就是必須有一定的數量。單靠一個Bug，很難看出整個研發系統出現了什麼問題。
只要Bug的數目一多，在經過統計、分析後，就很容易看出Bug後面潛藏符合80/20法則的某些規律、趨勢－80%數量的Bug重覆指向某些特定的20%目標。例如：某位Developer、某個功能、某支程式、某個被使用元件、某些特定的狀況。
但要找到這個規律，則需要在Issues Tracking軟體（如Bugzilla、Bugfree）軟體中自訂/新增其他欄位，並使用這些資料，才能在Bug結案時，統計判斷出發生問題的可能原因。
一般而言，筆者會建議至少需要以下欄位的資訊：根因、元件、Code檔名、功能（需求編號）、Developer，才有機會釐清這些Bug和這些資訊是否具有關連性。
另外，Defect Pattern的手法，其實不限於程式，舉凡流程、文件，皆可以應用SQA的手法和Defect Pattern的活動，提出具體改進的手法。
其他配合條件
除了上述Bug相關資訊，要找到這些規律還需要有參與開發/測試實務經驗的SQA，從品質的角度和專業來分析問題。
唯有對該軟體專案的開發流程/開發環境有一定了解的SQA，依照軟體專案的規模、性質的不同，形成實際判斷的「手感」。根據筆者參與專案的經驗，有經驗的SQA需要進入專案3個月左右（視規模、性質可能有所不同），對專案有一定程度的了解後，才有機會看出這些潛藏的規律。
另外，SQA的詳細活動，可以參考《SQA怎麼做的實戰教學》一文，這裏著重於撰寫Defect Pattern及其後的相關活動。
撰寫Defect Pattern
在確定Bug確實已形成Defect Pattern後，就可以整合這些記錄成為Defect Pattern。在這裏筆者直接以在Delphi平台的「Unit Transfer單位轉換」作Defect Pattern實際個案及重要欄位介紹。
一般資訊 包括了Defect Pattern標題(Title)：要求以一句話就簡捷說明了這篇文章主要達成的目標。版本(Version)：作版本控管和發佈的記錄。修訂記錄 (Revision)：每一版文件的修正內容記錄。關鍵字(Key Word)：可以達成效果、目標、使用的元件作關鍵字。倘若有全文檢索系統，這欄就可以省略了。讀者(Readers)：簡要說明寫作的對象。以及建議 (Suggestion)：作者對讀者的要求。
缺陷資訊 則涵蓋了問題描述(Problems)：寫Bug ID和Bug Title。問題發生處(Root Cause)：寫出發生問題的地方。解決方案(Solution)：列出錯誤的方式和正確的修正方式，和未來預防的手段。注意事項 (Attentions)：其他作者希望提醒的事項。
Defect Pattern的關鍵其實在「問題發生處(Root Cause)」。上圖範例內寫的只是發生問題的地方，但實際離Root Cause還有一段距離。因此，筆者建議讀者應用TOYOTA豐田汽車實施改善流程的「五個WHY」手法，重複「結果→原因」的過程，找到一次因、二次因…、直到找到無法再繼續向下探索的n次原因，用這個手法找到的原因才有資格被稱為Root Cause，也往往才是最根本的原因。
另外，Defect Pattern寫完後還需要經過驗證的過程。
驗證Defect Pattern
筆者通常會找一個沒有參與這個系統/專案的Devoloper，請他看Defect Pattern的草稿，並依照文件的描述步驟實際操作，以確定內容確實有效，發現有疑問時，則要求作者修正。
接著，筆者還會自己再看一次修改後的Defect Pattern，以確定文章的描述清楚、資訊齊全、沒有格式的錯誤。如果有必要，筆者還會再找其他人再Review一次，以確認內文確實正確、有效。
確認Defect Pattern後，則進行最後的Fan Out。
Fan Out
是品保領域內的特殊單字，指的就是從單點作扇形展開的意思，實際的行動就是分享、發佈、展開Defect Pattern。
「分享」時，筆者通常建議在部門的例行會議或是召開正式的會議，邀請高階主管參加，並請當事人也就是撰寫Defect Pattern的作者上台報告。
會使用這個手法其實有很多的目的。除了請更多的Devoloper再次確認內容，以釐清作者的盲點；另一個目標是讓與會的其他成員也能很快地了解這個問題的始末，除了能當場提出來討論，也能再思考一下自己是否也有類似的問題，在會後自筆者檢查；再者是讓成員知道高階主管也重視這件事，讓所有成員都有參與感，並感受到整個開發團隊在開發手法上的進步。
「發佈」時，除了得先修正Defect Pattern在「分享」過程中又發現的錯誤，SQA還需要以正式文件的型式，以書面或Email給所有成員，再儲存至組織內的固定位置，讓所有的成員方便查詢。
「展開」時，是特別重要、太常見的Bug，就需要某個資深的成員偕同SQA，主動以Defect Pattern內的關鍵字去搜尋資料庫，以偵檢此一Bug沒有在其他專案、程式中發現，最後再記錄「展開」的過程，以便未來又發現相同問題時，能了解搜尋的盲點，並以此修正Defect Pattern。
至此，關於Defect Pattern的活動才算完成。
小結 Defect Pattern其實上述活動是典型的「知易行難」，原理非常簡單，但卻不容易作到。
深究其原因，筆者認為有以下幾點。一是決定的老闆/主管缺少找Root Cause的「決心」和面對Root Cause的「勇氣」，以致於改善活動往往淪於形式，這是很多的組織/團隊達不到Defect Pattern預期效益的最主要原因。
另外是決定的老闆/主管不認為此一活動有價值，所以捨不得花此一活動的相關費用。但是，不願意作這些活動的結果，是這些費用往往又反過來提高開發成本。最後，就是開發成員的消極抵抗。這個和Devoloper個人的觀念有很大的關係，因為這不是本文的討論範疇，筆者以後再另文討論。
其實，僅執行Defect Pattern還是有一些缺點，這個部份筆者賣個關子，下回再分享。
