◆不要使用含糊的詞語（例如，好像，似乎）來描述發現的現象。
◆請考慮如下問題：
1.同一軟件中的相似功能是否有相同的問題？
2.其他的瀏覽器是否有相同的問題？
3.其他的軟硬件配置是否有相同的問題？
4.其他的區域（locales）是否有相同的問題？
5.不同的安排設置是否有相同的問題？
6.以前的版本否有相同的問題？
◆編寫bug report沒有什么定式，沒有絕對的范本，最基本的是能夠讓客戶或目標修改，瀏覽bug report人員看懂，而且在短時間內，而不需反復思考的。其他有時要考慮目標讀者的一些喜歡。例如有些類似的bug到底是合并還是單獨提交，bug的步驟劃分（到底是每一步都為一點，還是有些點可以合并）。在這一點上我覺得“靈活和適應”是很關鍵的。
◆在發現一個Bug并填寫完bug report之后，在review的時候，需要特別注意的一點是：這個bug report會不會讓其他人還有聯想或發揮的空間。一個好的bug report是不可以細分的, 換句話說就是這個bug是不會讓他人覺得你還有些地方需要在測試一下，或許還有其他的問題。例如，有個測試人員發現在輸入16這個數字（允許范圍內）且提交時系統會返回一個錯誤：不能輸入48以下的數字。這確實是一個錯誤，但是如果就只按現在的步驟提交，另一個可能會有這樣的想法：是不是輸入48以下的數字都會有這樣的問題呢？這樣他有可能要求你在測試其他的數據。這樣就延長了這個bug的生命期，而且浪費了大家的時間。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
