巧破軟件測試缺陷管理之痛[2] 軟件測試
一般在項目的開始階段發現缺陷數曲線會呈上升趨勢,到項目中后期被修復缺陷數曲線會趨于上升,而發現缺陷數曲線應總體趨于下降。同時處于OPEN狀態的缺陷也應該總體呈下降趨勢,到項目最后,三條曲線都趨向于零。項目經理可通過持續觀察這張圖表,確保項目開發健康發展。同時,通過分析預測項目測試缺陷趨于零的時間,以制定產品質量驗收和發布的時間。
實際上,BUG分析圖表會告訴我們很多有價值的信息。比如說,可分析開發和測試在人力資源的配比上是否恰當,可以分析出某個嚴重的缺陷所造成的項目質量的波動。對于異常的波動,如本來應該越測試越收斂的,卻到了某個點發現的故障數反而呈上升趨勢,那么意味著往往有一些特殊事件的發生。通過對測試缺陷分析,能夠給予我們很多改進研發和測試工作的信息。
(3)發布BUG分析經驗,提高團隊成員能力
分析得出來的BUG實踐經驗應該被記錄并發布,這樣其他的開發人員就可以通過學習這些經驗避免類似的錯誤。一個發布經驗最好的辦法就是知識庫,這將使得新的知識在項目內流動并被相關的開發人員所學習。
BUG分析帶來了很多的好處。第一個好處就是幫助產生BUG的開發人員總結經驗,并使他在將來避免類似的BUG。有時只修正一個具體的BUG而不去分析它產生的原因并不會幫助開發人員在日后得到提高,只有深入分析和資深開發人員的指導才能使開發人員成長和提高能力。
從這個角度來看,BUG分析的價值不僅僅是缺陷的預防,更大的好處是通過記錄和分析BUG,項目內的其他開發人員知道如何發現類似的錯誤。所以,我們可以通過某個開發人員產生的一個BUG提高整個項目團隊的實踐經驗,而不僅僅是盡快修正它。這樣,因為一個缺陷所浪費的時間也可以轉化為收益:確保類似的錯誤不會再發生。除了分享項目內的測試知識和經驗,BUG分析過程還可以促進開發更好的測試技術和工具,從而幫助發現類似的BUG。
如何高效地進行缺陷管理
(1)清晰缺陷分類,明確處理責任
首先要改變以前那種凡是BUG就是由開發人員負責的觀念。跟據缺陷內容可分為需求BUG與程序BUG。對于程序BUG是由相關開發人員進行處理,需求BUG則要交由需求人員進行處理,對于這種分法的好處就是明確了BUG處理的責任人。
測試人員從本質上來說與程序員還是對立的,如果為了一個不是軟件程序本身的問題形成與開發人員的對立,則會出現贏得戰役而丟失整個戰爭的情況。測試人員協調好與開發人員的關系,可讓他們更高效的關注軟件本身的缺陷。
(2)建立缺陷處理流程,減少無效運作
建立缺陷處理流程,這對測試人員和開發人員來說都是很有幫助的。BUG處理流程其實就是定義BUG處理過程的職責和權限,用明確的流程去指導如何對BUG進行日常管理,提高運作效率。
(3)使用缺陷管理工具:BUG管理庫
為了跟蹤和控制測試質量,便于管理測試發現的BUG,我們需要為項目配置一個專用的缺陷跟蹤數據庫,以便報告、查詢、分類、跟蹤、處理和驗證缺陷。因此,開發過程中使用一套BUG管理工具是非常必要。
缺陷管理工具應便于項目組和管理人員獲取正確、足夠的信息,以簡化信息共享流程,最大限度減少重復工作。BUG管理庫就是記錄、評估缺陷,并執行及維護系統配置,創造一個高效管理環境的最好工具。例如使用缺陷管理庫可以很方便制作各種缺陷分析圖表,從而預測項目風險或解釋測試結果。整個開發過程是BUG數從少到多,再到少的過程。從BUG數量的變化,也可以推斷軟件產品的成熟性,推斷產品的發布期。
(4)把管理制度和配置策略相結合
有了先進的缺陷管理工具,還需要有相應的管理制度與之相配套,否則BUG管理就只是一個擺設。目前BUG管理制度方面主要的問題是不重視測試,認為測試人員無關大局,隨便測測就行了,再或者就是雖然認識到測試的重要性,但卻走向了極端,制定了極其嚴格的規章制度。
例如無數瑣碎、難用的測試工單,非常嚴密的層級權力控制等。把一個需要靈活變化的工作變成了工業制造車間流水線的一個工種,讓測試人員陷入制度的泥潭,不能把主要精力投入測試工作本身。再或者就是項目負責人也沒有制訂明確的BUG處理流程及相關指導原則,讓測試人員在黑暗中摸索,走到哪兒算哪兒,不能給他們以切實有效的指導和幫助,把軟件的質量保證責任一股腦推到測試人員身上,任何問題都去指責測試人員。
最后,BUG管理制度還有一種常見的錯誤考核制度,就是項目主管用BUG個數去衡量測試人員的工作成績,誰發現的BUG多誰的工作就做的好。這是一個十分危險的傾向,將直接導致測試人員去重視BUG個數這個數字本身、而不是產品的真正質量。最后重申強調一點:BUG不僅僅是被修正,更重要的是根據BUG管理來提高軟件產品質量。
原文轉自:http://www.anti-gravitydesign.com