Tester vs. SQA - 5/5 SQA思維與活動 - 通達人驛站
2010/10/15

Tester vs. SQA - 5/5 SQA思維與活動

Tester vs. SQA - 5/ 思維與活動

這一篇文章是我投稿到ZDNet的《SQA怎麼做的實戰教學(上)(下)》的原稿,該文標題經編輯修正。

在這一篇文章中,我們將進一步從上篇文章《Tester vs. SQA - 4/ 關係與差異》中的差異處,繼續說明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所找到的解決方向,不但只是踫運氣,也是浪費時間和金錢。

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

脫逃點(Escape Point)


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

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

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

所以,當客戶發現某個Bug時,就要再繼續找為什麼Bug無法被既有的Test Plan/Test Case測出的原因:
  • 因為Test Case的Coverage不足?所以根本沒有發生Bug條件的Test Case?
  • 或是Test Case的條件不足,有其他條件但就是沒有發生Bug的條件?
  • 或是根本沒有執行該項Test Case?
  • 或是有以上之外的原因?

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

改善方案


一般而言,筆者會採用兩種方法:
  • 矯正措施(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的精神是相同的。

另外,這個步驟其實還是延續《Tester vs. SQA - 4/ 關係與差異》一文中打靶的觀念:「射『對」』標比射『準』目標來得更重要。」的精神:執行的結果,取決於一開始找到的根因是否準確。

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

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

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

筆者認為這才是業界中難得看到認真執行SQA手法的原因。

認真執行的人少了,真正的SQA自然也就少了。
 Related Posts with Thumbnails 

0 意見 :

張貼留言