背景介紹
軟體中的Bug是軟體開發過程中的"副產品"。通常，Bug會導致軟體產品在某種程度上不能滿足用戶的需要。每一個軟體組織都知道必須妥善處理軟體中的Bug。這是關係到軟體組織生存、發展的質量根本。可遺憾的是，並非所有的軟體組織都知道如何有效地管理自己軟體中的Bug。
管理流程
系統管理員在BUG管理工具中建立項目名稱，以及和被測試的項目相關的人員名單；給相關人員指定相應的角色和許可權。2. 測試人員發現BUG並在BUG管理工具如DevTest中記錄，測試負責人審核BUG的有效性。Bug的跟蹤處理過程參見缺陷跟蹤處理流程。3. 測試負責人跟蹤BUG分配，以確保BUG沒有被忽略。4. 測試負責人負責定期生成測試進展通報表，向項目組成員、項目經理、測試部門經理、高級經理通報每天產生的BUG、BUG總數、BUG狀態等有效信息；測試負責人根據這些數據調整測試策略和資源分配或者判斷是否可以結束測試。對於爭議的BUG，報請測試經理，由測試經理組織討論後進行裁決，並生成測試問題報告單。5. 結束測試項目後，測試負責人利用BUG管理工具生成BUG統計數據，分析項目的BUG作為編寫測試分析報告數據來源之一。
管理目標
bug能夠引起軟體運行時產生的一種不希望或不可接受的外部行為結果，軟體測試過程簡單說就是圍繞缺陷進行的，對bug的跟蹤管理一般而言需要達到以下的目標：
確保每個被發現的bug都能夠被解決；
這裡解決的意思不一定是被修正，也可能是其他處理方式（例如，在下一個版本中修正或是不修正），總之，對每個被發現的BUG的處理方式必須能夠在開發組織中達到一致；
收集bug數據並根據bug趨勢曲線識別測試過程的階段；決定測試過程是否結束有很多種方式，通過bug趨勢曲線來確定測試過程是否結束是常用並且較為有效的一種方式；
收集bug數據並在其上進行數據分析，作為組織的過程財富。在一個運行良好的組織中，bug數據的收集和分析是很重要的，從bug數據中可以得到很多與軟體質量相關的數據。
處理方法
通常大家發現軟體bug時會對軟體bug進行分類，可分類的方式只有一種，就是嚴重極別,難道沒有其它的分法嗎。比如我們碰到下面這種情況，測試人員發現有一種功能是必需加入進去的，這時他與程式設計師說，程式設計師說沒有時間或是不必要，這時這種情況則會形成兩者的扯皮，最終的結果也就不了了知了，這樣會挫傷測試人員的積極性，下次他們再也不會盡心的考慮產品的問題，只要可以運行就可以了。其實這種情況是可以解決的,DevTest中融合進一個新的軟體bug分類概念，從而有效的解決這個問題。
輔助工具
bug管理是在軟體生命周期中獲取、管理、溝通任何變更請求的過程（從變更的建議到變更的解決）。可以確保你的問題如需求或者bug被跟蹤管理而不丟失。如果用相應的工具就可以成功地進行bug管理。
首先要讓大家改變以前那種凡是Bug就是由開發人員負責的觀念，其次需求人員的工作量要加大，不過廣泛的了解需求是他們的本份工作，想來不會很困難，還有必需要有有效的Bug管理工具，比如DevTest，不要出現那種對需求人員說了，可過兩天就忘的情況出現，這時需求Bug的生命周期會出現跨越兩個軟體開發周期，因為有些需求會在下一版實現，這時測試人員需要延長對這些需求Bug的管理，不過我想這些需求是他們提出的，會有興趣對這些Bug進行管理的。
