四、項目實施經驗教訓
測試作為項目開發的后一環，錯誤、延時、疏忽等都可能在測試階段表現出來，如何有序管理和分析各種問題對質量控制和過程改進非常重要，使用web based系統是一個好的實踐。
在項目組內，對Bug采用數據庫系統進行跟蹤并不困難，因為主要是測試人員提交Bug報告，測試人員使用多，相信測試人員對使用中心數據庫的好處是很了解的了，只要項目經理支持很好辦了。如果要對其他缺陷，如需求變更，也這樣管理不是那么容易了，在技術上當然沒有問題，難在工作方式的改變，雖然用Email和文檔管理無法實現工作流的自動化，也不如數據庫系統提供那么多的分析和報告選項，但在小規模的項目中依靠人工管理也可以做得井井有條。我們在多個項目的實施中遇到這樣的情況，有的項目隨時都有需求變更，而且變更的數量不少，項目組主動提出想用數據庫系統來管理；有的項目剛起步，第一個階段的開發業務功能不多，推行的時候阻力很大。我的初級目標是有序地管理錯誤和變更，在實施手段上有沖突時，不要操之過急，融洽的關系對項目的成功是很重要的。往往是有了成功的案例后，回頭推廣又變得容易了。實施新過程時好先局部試點，采用PDCA循環，不斷總結經驗，再推廣。
使用缺陷數據庫，可以制作得到各種缺陷分析圖表，從而預測項目風險或解釋測試結果。下面兩張圖都是Mantis生成的缺陷圖，從累積錯誤打開圖，分析錯誤生成趨勢，在發現錯誤報告未收斂時發布軟件，顯然風險很大，當然使用圖表時還應結合實際，在曲線平坦時，是否開展了測試工作，曲線上升時，錯誤的嚴重性等級如何等。從嚴重性等級的柱狀圖可分析被測系統的總體狀況。在發布管理不規范的組織中，當產品質量問題突出時，測試組可以通過解釋這些圖來闡述測試結果，從而規范發布過程。
第一部分提到的根本原因（Root Cause）域，他有助于使開發人員的注意力集中到引起嚴重、頻繁問題的領域，從而消耗少的資源改進過程取得顯著的成果，這是我在過程改進時常用到的80/20法則。在項目實施時，實際情況并不理想，因為開發人員忙于改Bug，少有主動寫錯誤發生的根本原因的，這需要開發人員的配合和管理者的支持。
缺陷數據的使用應謹慎，不要將錯誤個人化，應保證數據的真實性，否則數據對過程改進沒有意義。
實施過程中，大家會對工具提出很多需求，應評估哪些是共同需求、核心需求，系統修改復雜程度，對當前系統和系統升級的影響。測試組在實施過程中，對不同角色人員的工作流程有了深入而準確的了解，同時可以進行工作流程的改進。
使用開源系統的利弊
由于開源系統的代碼是公開的，用戶可自行維護和定制，大家也可以提交新特性和功能擴展要求，而不必受制于商業系統的制造商。開源系統的用戶遍布世界各地，Bug反而容易發現，同時公開源代碼中低效率的程序也容易被發現和修改。當然越是流行的軟件，生命力越強，Bug清除和新特性增加越快。
開源系統與其他工具的集成比較差，不如商業系統提供整個軟件開發生命周期的工具的集成，如項目管理、需求管理、建模、自動化測試、缺陷跟蹤、配置管理等有機集成，實現整個開發流程的自動化。但一般的中小企業，大多沒有實力配置全所有系統，另外，不同廠商優勢不同，主導系統也不同，有的企業需要根據自身的特點選擇不同廠商的工具，所以即使購買商業工具也未必能將所有系統很好地集成。
開源系統是免費的，但有人提供收費的系統維護和定制服務。
五、小結
本文主要探討缺陷跟蹤管理的流程、工具和實施問題，缺陷跟蹤在技術上并不難，而是難在管理上，好的工具有利于管理和交流，的項目組應意識到有效的交流方式是多種多樣的，不應該單依賴系統，這樣才有利于提高團隊的戰斗力，而不是把重點放在追求系統功能的十全十美。有些缺陷跟蹤系統有Knowledge Base 功能，這對公司知識庫的累積也很有效；有的系統對不同用戶生成相關的To-Do-List，方便日常工作；有的對每個發布版本都有詳細的缺陷報告。總之，花費時間和精力完善錯誤管理系統是值得的，這是質量管理和提高的基礎。
參考書目
《測試流程管理》 北京大學出版社 作者Rex Black 2001年3月第一版
《CVS開源軟件開發技術》 機械工業出版社 作者Karl Fogel 2001年6月第一版
關于作者
蔡琰，外企QA主管，有三年電子商務領域QA、測試主管經驗及多年的開發經歷。目前關注基于J2EE構架的web系統的功能測試和性能測試、自動化測試、過程改進。現在上海，您可以通過電子郵件cindy_cai@sina.com 和她聯系。
