2009/12/28

Tester vs. SQA - 4/5 關係與差異

這一篇文章是我投稿到ZDNet的《軟體測試不等於客戶滿意》的原文。

當顧客拿到經過軟體測試員(Tester)反覆測試過的軟體,顧客是否就會滿意這樣的軟體品質?

根據筆者的經驗,顧客通常不滿意這樣的品質。

追根究底後可以發現,Tester與品質保證工程師(SQA) 的工作相比,有相當大的差異,並不能完全保證軟體品質。如果再考慮到軟體開發生命周期拉長,驗收時往往就可以看到顧客並不滿意的軟體品質出現。

所以當筆者面對客戶預期的落差時並不感到十分意外時,筆者通常會被繼續問到:到底Tester與SQA所負責的業務範疇有何不同?

為了回答這個問題


筆者通常會反問其一個問題:「作家和記者有什麼不同?」

作家和記者的工作都是靠動筆桿賺錢,但你會因為這兩個工作都是動筆而認為這兩個工作相同嗎?筆者想應該是不會!

因為大家都知道這兩個工作並不相同。

作家比較偏向透過蒐集到的資料無中生有地寫出別人沒寫過的文章、小說、詩,以提供讀者前所未有的體驗;而記者則是透過訪談掌握、釐清事實真相等程序,理出頭緒、邏輯,其後再以新聞寫作的方式描述事實真相。

也就是說,雖然同樣都是動筆,但因為動筆的動機、表達方式、呈現方式,以及所需技能等不同,因此產出物也是不一樣的。

SQA和Tester的關係


SQA與Tester的差異其實和記者與作家的狀況相近:Tester的工作與作家類似,需要創造力以提出他對於某項主題的詮釋;至於SQA的工作性質則與記者相近,需要特定的程序,呈現他對於某項主題的客觀了解。

相信透過上述舉例您以比較了解Tester與SQA的差異,接下來,筆者將進一步探討Tester與SQA的差異,以釐清兩者的不同:


差異一:工作階段


Tester專注於軟體開發過程中的開發後測試工作。亦即配合開發人員的開發工作制定驗證的手段,只要滿足此一階段的要求就算達成工作目標。

SQA則專注於整個軟體開發過程。從客戶提出要求(Request)開始,一直到客戶簽收與使用軟體的每個過程,都有對應的品質目標需要達成。

差異二:工作方式


Tester偵知到錯誤(Bug),通常已到了完成軟體開發的後期階段了,在此狀況下其多半只能依錯誤、缺陷的嚴重情況與否選擇要修正或者是不修正。另外若其是選擇不修正,則必須在相關文件中提出不修正該錯誤的替代方案(編按:又稱Work Around)。

而且無論修正與否,Tester都算是在「事後」對軟體品質提出意見。

相較於Tester,SQA則比較像是「事前」預防軟體缺陷。最明顯的例子是在開發的每個階段,都要求工程師們進行確認與驗證 (V&V)。透過該作法,其除可確認軟體需求沒有因為層層作業而偏移、短少,亦有機會在開發初期就偵測到軟體的潛藏缺陷。

差異三:工作對象


Tester專注於「軟體測試出的結果」,也就是驗證(Verification)的部份。測試通過,表示軟體的品質依照輸入的要求是可以接受的,因而對Tester來說,測試軟體的結果決定了他對軟體的信心。

相較於Tester,SQA則專注於「軟體的開發過程」。除了前述的驗證(Verification)外,SQA更注意確認(Validation),也就是各個階段確認活動標的(Target)的確符合客戶的需求,以避免產品在一連串實現的過程中偏移客戶實際的需求;在確認後再考慮驗證的結果,進而決定產品品質是可以接受或不能接受的。換句話說,SQA僅對經V&V過程的軟體開發過程有信心。

差異四:缺陷應對


Tester專注於發現軟體缺陷,發現之後只能回報給軟體開發者,以及協助其了解、釐清問題發生的原因,至於缺陷的矯正、或改善措施,則無Tester置喙的餘地。但在程式設計師(Programmer)修正錯誤(Bug)後,Tester必須重提或修正測試個案,並且在下一個循環(Cycle)中實際測試修改過的軟體已無缺陷、錯誤。

SQA則專注於預防缺陷,以及找到導致問題發生的根本原因(Root Cause)、解決該根因可能產生的相關問題,甚至會被要求一併剔除可能發生此一缺陷的原因,進而降低可能會出現的軟體錯誤、缺陷,達到提昇軟體品質水準的目的。

差異五:工作風格


Tester的工作特性是務實、被動。

「務實」是指利用與執行已經設計好的測試計畫、個案,得知軟體的品質水準;至於「被動」則是指因為Tester的測試計畫、個案是建構於原先已知的軟體需求、功能,所以只要需求或功能變更了,Tester就只能被動的接受。

SQA的工作特性則比較抽象、主動。

「抽象」是因為SQA致力於催生高品質軟體,只要是能有效達到此一目標的手法,都是SQA可採用的方法,因此實務上可能會因為專案的特性、成員或其他因素的不同,使工作手段有所差異,無法按照同一個模式行事。而所謂的「主動」則是指SQA發現了問題,不會僅解決浮現的問題表面而已,會一直伸入問題的根因,並設法消除根因,並保證相關的問題不會再發生。

從上述五個差異可發現Tester與SQA因為關注的焦點與解決軟體錯誤的基本觀念完全不同,所以在面對問題時採取的行動也會有上述說明的差異。

最明顯的差異


筆者通常會舉更簡單的「打靶」例子來加強說明二者的差異。

在打靶的時候,經常是一群選手上了射擊台後,面對一整排的射擊靶,第一個選手射第一個靶位,第二選手射第二個靶位,其餘依此類推。每個靶的分數就是將靶上每個子彈命中的位置來計算,加總後就是該靶的分數。團體分數就是加總同一隊中每個靶位的分數。


假設每個靶位都要設擊五發子彈,但某個靶上卻有六發子彈(如圖1),已經超過計算子彈的上限,這時就以無效靶(0分)計算了。

反觀(圖2),即使命中的位置也過度的偏散,但因為靶上命中的子彈沒有超過,最後得到的分數還是會比(圖1)的靶來得高。

如果團體想要獲得高分,首先就必須確認每位選手正在瞄準的靶是正確的,不然即使你瞄準的再準確,射錯了靶,不但自己少了一些分數,同隊的選手也會因為靶上命中彈數超過上限而失去分數。

小結


從上述的例子可以看到,射「對」目標比射「準」目標來得更重要。因為射不準還可以在下一發子彈修正,但一旦射錯目標,只是繼續上一發的錯誤,結果並不會因為射準了而更好。

換句話說,「確認」不但是非常重要的工作,也正是Tester的工作中缺乏的。

下一次,筆者將以更實際的例子,說明這兩個角色的思維與實際工作的差異。

沒有留言:

張貼留言