Defect Pattern實作 - 通達人驛站
2010/10/20

Defect Pattern實作

這一篇文章是我投稿到ZDNet的《Defect Pattern的實作》一文的原稿、加上補充後的版本。

筆者在《Tester vs. SQA - 5/ SQA思維與活動》一文中介紹了SQA的一系列活動,也在《軟體開發的「已病」和「未病」》中介紹了「已病」和「 未病」的概念。

在這篇文章中,筆者將進一步介紹融合「已病」觀念的Defect管理手法,藉由藉由不斷重覆此一PDCA循環的手法,即可有效提昇軟體品質。


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的詳細活動,可以參考《Tester vs. SQA - 5/ 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還是有一些缺點,這個部份筆者賣個關子,下回再分享。
 Related Posts with Thumbnails 

0 意見 :

張貼留言