組織Structure：測試人員應該採用深思熟慮的，小心謹慎的方法執行測試，並且做詳盡的記錄。這樣可以促使他們對測試下的系統有很好的認識。當錯誤發生的時候，一個有組織的測試人員能夠知道最早出現問題?
重現Reproduce：測試人員在編寫bug report之前必須在檢查問題是否可重現。如果錯誤不可再重現，仍然應該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫bug report之前反覆嘗試3次。
隔離Isolate：在嘗試編寫bug report之前，必須試着隔離錯誤。可以採用改變一些變量的方法，如系統的配置，它可能可以改變錯誤的症狀。這些信息可以爲開發人員着手調試提供思路。
歸納Generalize：在測試人員發現了一個已隔離的，可重現的問題後，應該對問題進行歸納。同一個問題是否出現在其他的模塊或其他的地方？同一個故障是否有更加嚴重的問題？
對比Compare：如果測試人員以前曾經驗證過現在出錯的測試用例，那麼他就應該檢查以前的測試結果以檢查相同的條件是否通過以前的測試。如果是的話，那麼這個問題就象是一個迴歸的錯誤。注意由於同一測試條件有可能出現在多個測試用例中，這個步驟就不僅僅只是檢查一個測試用例在以前的多個結果。
總結Summarize：在bug report的第一行寫上錯誤的總結是非常關鍵的。測試人員要花些時間思考已發現的錯誤對客戶有何影響。這不僅僅要求測試人員編寫的報告要能夠吸引讀者，使和管理層的溝通清晰，還要能夠幫助設置錯誤修復的優先級別。
精簡Condense：在bug report的初稿完成後，測試人員應該反覆閱讀它，集中剔除那些沒有關係的步驟或詞語。隱含的或模糊的說明和那些由於對沒有任何關係的細節或者那些在重現錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標。
消除歧義Disambiguate：測試人員在精簡空話的同時或其之後隨即應該再仔細檢查報告是否有會產生誤解的地方。測試人員應該儘量避免使用模糊的，會產生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產生爭執的詞語。
中立Neutralize：如文中所述，作爲壞消息的傳遞人，和善地提交消息是一個挑戰。如同所有的錯誤總結一樣，獨立的bug report在措辭方面應該保持公正。攻擊開發人員，指責潛在的錯誤，企圖詼諧或使用挖苦將引起開發人員的憎惡，並且使注意力從“提高產品質量”這個大的目標上轉移開了。謹慎的測試人員只用Bug report來描述事實。
檢查Review：一旦測試人員感覺bug report是他能夠編寫的最好版本，他應該將報告再給一個或多個同行進行檢查。他的同事們也應該給出一些建議，爲了澄清問題不斷地提問，如果適當的話，甚至可以挑戰“錯誤成災”的結論。在允許的時間裏，測試小組應該儘可能提交最好的bug report。