初到現場發現原有的bug跟蹤很不方便，則在空閒之餘搭建了一個bug跟蹤工具。在談論bug管理的問題中，大家列舉了很多bug跟蹤軟體。但我覺得工具只是一個部分，主要的還是在bug管理的流程上。
在這些bug管理工具中，bug的極重要屬性就是「狀態」。一般可分為「新增(New&Active)」，「處理中(in progress)」，「已修正(Fixed)」，「重新打開(reopened)」，「關閉(Close)」等。
就這幾個狀態而言，明眼人一看就清楚一個bug從發現到排除要走哪些流程：
1、測試人員發現bug，提交。bug狀態為New&Acitve
2、開發人員接收bug。bug狀態為in progress
3、開發人員修改完畢並提交。bug狀態為Fixed
4、測試人員針對開發人員的解決方案再次對bug進行驗證測試。如果bug依然存在，則把bug狀態設置為reopened，流程返回至第二步。如果問題已經解決，就直接設置為close。
經過以上四個步驟，整個bug的流程就基本走完了。
看似流程非常簡，可是在實際使用中還是會發現一些問題：
1、bug信息不全。
有的信息如項目，模塊，指定處理人等。依據這些信息會用來作統計分析，哪個項目，哪個模塊，誰的bug多，誰發現的bug多，誰改的bug多等等，則可以大致看出一個人的工作量和工作質量。所以測試人員在填寫bug問題單時，不要嫌麻煩。應該把涉及bug相關的信息完全寫出來。
2、提供的信息不準確。
有的bug描述一帶而過，表述含糊不清。只是說出了錯誤並沒有清楚的描述錯誤的現象是什麼，提示信息是什麼，怎麼操作才可以出現等。這樣的bug交給開發人員，只會給開發人員增加負擔。因為當開發人員拿到bug後，發現不明之處還需要再做測試才可發現更多的信息去解決bug。或者與相關測試人員討論並詢問詳情，有時要多次在反饋信息當中才能明確bug的目的。這無疑造成了研發周期的無限延長。
3、開發人員關閉bug
只有bug的提交人(也就是發現人)才能關閉bug，開發人員只能使用兩種狀態，即「處理中」和「已修正」。
4、bug的重要性
這個重要性是在bug管理軟體中無法體現和度量的，這個任務主要體現在測試這邊。如果當測試人員發現了一個bug，及時與開發人員溝通時無法重現bug，此時連測試人員都不知道這個bug是怎樣操作才出現的。對於這樣不能重現的bug幾乎就不能算是bug，也是最讓人頭疼的問題。那麼作為測試人員，其任務就是要儘可能地找出bug出現的規律。嘗試各種可能，即使不能重現也起碼要讓開發人員知道測試人員是怎麼做的，而減少開發人員的再操作的時間。