No. 5

前一篇文章《軟體測試不等於客戶滿意》，我們從Tester與SQA的差異處來說明二者的不同。在這一篇文章中，我們將進一步從上篇文章中的差異處，繼續說明SQA在軟體開發過程中的工作。

Tester的焦點集中在軟體的每個版本中：舉凡加入多少新功能？有那些功能變更？上個版本的Bug是否都已經被解了？Developer又自行測出那些Bug？還有那些Bug沒有解？都是必須注意的要項。

Tester在知道上述問題的答案後，所採取的行動是「我將要用什麼方法去驗證軟體？」，以確認這個版本的軟體已經達到宣稱的功能（品質）水準，進而提供他們信心。

所以，Tester會去設計新的Test Case以Cover這些新的/修改後的程式。換句話說，測試的函蓋率（Coverage Rate）越高，他們對於軟體品質的信心水準越高。

SQA的焦點則與Tester不同。他們關心的是在每個版本中：加入的新功能/變更是否都照開發程序走完流程？上個版本發現的Bug是否都已經釐清？

如果是後者，他們還會再繼續一連串的活動以改善既有的（開發）系統：

SQA認為藉由這些手法能有效地改善（開發）系統，而藉由持續不斷地重覆這些活動，將可提供他們對於軟體品質的信心。

實務上的操作

當我在擔任SQA時，看到Bug時並不會每個Bug都去追，而是信任Developer由他們自行對Bug提出解決方案，我只去統計追蹤這些Bug的後續發展，直到我發現Bug 開始已經形成某種模式（Pattern）時，我才會介入。

因為，根據80/20分則，80%數量的Bug會同時指向某些重覆、特定20%的目標，例如：某個Developer、某個系統的某個功能、某支程式、某個被使用元件。

由於對象明確，所以我會集中80%的精力在這些目標上，以避免寶貴的SQA資源過度發散，使工作失去焦點。

例如當發生「使用A Library時常會發生錯誤」的模式出現時，這時我會繼續追兩件事：錯誤的原因（Root Cause）；脫逃點（Escape Point）。

錯誤的原因（Root Cause）

我會一直重複「結果→原因」問為什麼的過程，以找到一次因、二次因…、直到找到無法再繼續向下探索的n次原因，這個原因通常被稱為「根因」（Root Cause）。這個過程類似TOYOTA豐田汽車實施的改善流程方法「五個WHY」，一旦發現問題便接連問五次「為什麼」，藉此看清問題的根因。

假設問題是「使用A Library時常會發生錯誤」時，原因有可能是：

．濫用(abuse)，如：原本應該使用Y元件，但使用了Z元件；

．元件本身就有問題，即使依照A Library的User Guide操作，仍然會發生問題；

．誤用(misuse)，例如：原本應該用function big(a, b, c) ，卻使用成function big(a, b)

假設原因是誤用(misuse)時，我會再進一步去釐清Developer會誤用的原因：

是因為Developer不知道該如何正確使用元件？還是Y元件和Z元件設計的功能太相近了，即使說明了，也很容易讓人搞混以致於誤用？

假設原因是「Developer不知道該如何正確使用元件」時，我又會再進一步去釐清「Developer不知道該如何正確使用元件」的原因：

是Developer沒有看User Guide就開始Coding？又或是Developer根本不知道有User Guide？

如果原因是「Developer沒有看User Guide就開始Coding」，那表示是Developer明知道有User Guide，卻沒有看。這時候就要再去問：

為什麼Developer沒看User Guide，但Team Leader不知道？是給Developer的時間不夠，連看的時間也沒有？還是已經給Developer足夠的時間看User Guide了，但Developer還是沒有看完？

每個問題都可能至少有一個以上的根因，而找對的Root Cause遠比找解決方案重要，因為找到對的Root Cause才有可能找到對的解決方案，否則依照錯的所找到的解決方向，不但只是踫運氣，也是浪費時間和金錢。

找到Root Cause後接下來就是要找到「脫逃點」。

脫逃點（Escape Point）

通常是指既有的系統內，因為某項檢核、確認機制失效或未發生作用，以致於無法透過既有系統篩檢出隱藏的缺失，才導致異常狀況在系統外才被發現。

假設系統是個捕魚的魚網，如果發現網外有一隻比魚網孔目還要大的漏網之魚，這時候你得先確定是捕進來的魚漏掉了？還是根本捕不到這條魚？

假設是前者，你還得繼續確認是魚網的某個地方破了？還是這個魚網的孔目有方向性，魚從某個方向進來會溜掉？或是有其他的原因？

所以，當客戶發現某個Bug時，就要再繼續找為什麼Bug無法被既有的Test Plan/Test Case測出的原因：

．因為Test Case的Coverage不足？所以根本沒有發生Bug條件的Test Case？

．或是Test Case的條件不足，有其他條件但就是沒有發生Bug的條件？

．或是根本沒有執行該項Test Case？

．或是有以上之外的原因？

無論如何，都一定要找出缺失會從既有系統溜出去的原因，才有辦法改善現有的網，以避免相同的問題再度發生。

在下一篇文章中，我會說明如何改善。

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