No. 5

在上一篇文章中，我說明了如何找出缺失發生的原因，現在我將闡述改善的方法。

一般而言，我會採用兩種方法：矯正措施（CA, Corrective Action）和預防措施（PA, Preventive Action）。

CA通常是矯正既存異常狀況，或是排除造成異常狀況原因的對策。例如前面的「使用A Library時常會發生錯誤」問題，CA就是：透過正確的方式修正Code。PA則包含排除Root Cause、Escape Point、或類似狀況的對策。

Root Cause和Escape Point前面已經說明了，只要分析出的Root Cause和Escape Point夠正確，一般而言要提出排除這類狀況的手法並不困難；倒是「類似狀況」則需要再多說明。

所謂的「類似狀況」是指會發生此一缺失，但卻可能不是目前Root Cause的其他原因。例如前面的「使用A Library時常會發生錯誤」問題的Root Cause 假設是：「給Developer了解Guide的時間不夠」時，就可以把「類似狀況」判斷為「Developer不知道該如何正確使用元件」，以找出更多 的「類似狀況」，例如：使用手冊說明/案例不夠清楚，以致於不易理解；缺少精要的Training Material，以致於無法縮短上手的時間；Bug Pattern未加入此一案例，以致於無法從過去的錯誤中很快地學習正確的方式。

用這個方式，很快的就能網羅一堆可能造成類似狀況的對策。

Fan Out

則是個特殊的單字，其實指的就是從一個點扇形展開的意思。放在SQA的領域，可以當成改善案例展開、或分享。

「展開」的應用情況，可以在了解PA、CA後，一併作的處理。以上面的例子「Developer A因為不知道該如何正確使用元件，所以使用Y元件時，總是會誤用」。如果我來作Fan Out時，會請Developer A去Search過去他曾修改過、使用Y元件的程式，以確認是否重覆誤用，以提前將這個問題解決。

「分享」的應用情況，以前面的「Developer A誤用Y元件」的例子來說，我會請Developer A作出Y元件的Bug Pattern，並請他對Development Team報告，讓其他的Developer也能很快地了解這個問題的始末，並很快地偵檢出各自的Code是否也有類似的問題。

確認

當SQA作完上述的活動後，為了確認問題的解決手法真的具有解決問題的能力，一般而言會需要一段時間觀察缺陷是否還會復發。因為客戶最終是否滿意，取決於這些解決手法是否有效。

確認所需的時間，通常會視問題出現的難易度來決定。一個越容易重製（Reproduce）的問題，就越容易確認問題是否被解決，所需觀察的時間也越短。另 外，能提供確認的對象越多，其結果也就越能作為確認的依據。例如：Beta版散佈的對象越多，可以確認改善方案的有效性保證越可靠。

結語

上述的步驟，在某些公司的名稱雖略為不同，在執行順序上也略有不同，但流程背後執行PDCA的精神是相同的。

另外，這個步驟其實還是延續《軟體測試不等於客戶滿意》一文中打靶的觀念：「射『對」』標比射『準』目標來得更重要。」執行的結果，取決於一開始找到的根因是否準確。

找到越準確的根因，經過上述步驟的結果也就越有效。射不準正確目標還可以在下一發子彈修正；一旦瞄準了錯誤目標，就不會因為你下一發射準誤目標就變得更好。

此外，上面的手法其實非常簡單，一般人有心只要稍加訓練後就能很快學會，但往往很不容易作到。

除了因為在開始之前，就必須先建立一個明確、有效的流程（這個流程的形式不是重點，導入CMMI、ISO都可以辦到）之外；也因為建立流程者眾，但想認 真、徹底執行流程者寡。因為從筆者過去觀察到某些未導入CMMI、ISO的公司也可以有相同效果來看，真正的關鍵取決於管理者的決心與遠見。

我認為這才是業界中難得看到認真執行SQA手法的原因——認真執行的人少了，真正的SQA自然也就少了。

（全篇完）

引用來源: http://www.zdnet.com.tw/enterprise/column/Prudentman/0,2003032119,20144113,00.htm