bugzilla作為測試人員常見的測試工具，被所有人熟悉和使用著。
可是，bugzilla究竟給我們帶來了些什么呢？
第一，bugzilla給了測試人員話語權。我們通過它，作為一個平等互利的角色向開發人員，官方的，正式的發出我們的成果宣言：一個bug。
第二，bugzilla給了測試人員平等權。測試人員不再是開發人員的幫手，大家是從不同的視圖來看待一個產品的質量。 bugzilla是作為開發人員和測試人員交流的平臺。 同時，這個交流平臺也連接了項目管理，過程管理，需求人員，設計人員，銷售人員，技術支持人員，和終客戶，是大家能有一個平臺去交換各自的想法。
第三，bugzilla使得測試人員能使用一個標準化的對象去進行信息內容的溝通。
第四，bugzilla使得測試人員能夠更加迅速的了解產品的當前質量狀態，從而調整各種計劃和工作。
第五，bugzilla使得測試人員能夠積極的參與到產品的管理過程中，對整個產品的管理提供更多的技術細節和過程參數。
對于如何使用bugzilla進行項目管理，我們不妨舉幾個例子：
例子一：我們在測試過程中，經常會遇到這種現象，是一個模塊會突然爆發出很多bug來。難道bug真的那么多嗎，其實很多時候，是因為開發人員在修改一個bug時，引起其他已經修復的bug被reopen或者導致更多的新bug。
我們如果有一個機制，去監控 近3天內，新加的bug的原因。那么，這種問題能夠作為一個風險進入我們的風險管理過程。如果有相應的風險管理，那么執行。如果沒有，需要加入。并且，根據實際情況，我們來判斷，還有多少潛藏的bug會以這種方式出現。
例子二，我們在做測試計劃的時候，很難說我們的測試各個階段都能夠很詳細的制定出內容來。比如回歸測試，到底哪些東西要做回歸測試呢，什么樣的頻度，什么樣的深度？
我們可以在功能測試結束前的2周，對現有的bug進行分析，依據bug的在各個模塊的分布數量，優先級的加權等，來確定哪些需要重點進行回歸，那些可以忽略。從而對各個模塊的功能測試用例進行篩檢，從而得到回歸測試需要執行的規模和頻度。
例子三，當一個產品被release之后，或者一個sprint結束之后，我們也可以對bug進行分析，通過bugzilla自帶的很多圖表，我們能夠對上個階段的產品質量有一個很直接的可視化分析，然后寫出QA角度的分析報告來，提供給管理層和開發團隊作為參考，從而在下一個階段中能夠更好的提高質量和效率。甚至，可以以QA的視角，去管理下個階段的開發過程和質量保證過程。
總之，bugzilla不是僅僅作為我們QA跟開發交流的工具，還可以作為測試驅動開發的工具，可以作為產品質量衡量的工具。
