如何記錄一個大家認為好的，尤其是開發人員認為好的Bug呢？撰寫缺陷報告的一個基本原則是：客觀地陳述所有相關事實。
一個合格的Bug報告應該包括完整的內容，至少應該包含五個方面：發現問題、預期行為的描述、問題重視步驟、問題出現的環境、錯誤行為的描述。報告發現問題的版本，開發人員需要知道問題出現的版本，才能獲取一個相同的版本來進行問題的重視。版本的標識有助于分析和總結問題出現的集中程度，需要注意的是，有些Bug可能會在不同的版本中出現，例如，某個BUG在版本1.1中出現了，測試人員錄入了Bug，ID為101，開發人員也進行了修改，經驗證關閉了。但是，改Bug到了版本1.4時又出現了，這時，有些測試人員回頭把Bug101的狀態改成Reopen，這時錯誤的，因為這個Bug是在新的版本中出現的，即使是同一種現象，甚至是同一個原因造成的，也不應該Reopen，而是新加一個，因為這代表了一個質量回歸問題。這個缺陷確實又出現了，因為這個缺陷造成了損失，測試人員需要重新測試、驗證并進行報告，開發人員需要再次修改程序并編譯，如果Reopen,則可能造成質量統計時漏算了一個缺陷。
正確的做法是，錄入之前再多做幾次嘗試，盡量把操作步驟縮減到必須要執行才能重現錯誤的幾個步驟。
