如果在一開始你就不能成功的使軟件行為發生改變，那么利用文檔作為一種使bug report繼續有效并且有可能改變開發人員情緒的方法，集中精力在描述錯誤信息的詞語和文檔上。不一致的矛盾可能可以提供構思錯誤的線索。
“當我點擊文件à打開，應用程序崩潰了，清除了我的硬盤，并且踢到了我的貓�！�
這是一個令人信服的bug report。你可能不需要參考用戶手冊來解釋文件à打開功能制造了騷擾你寵物的這一功能不是軟件設計的功能。然而每天我們經常處理的那些普通的，嚴重程度低的錯誤不是這樣的清晰，并且導致組織采取的措施同樣也不清楚。
成為bug的擁護者
當你提交一個bug report的時候，你就成為了bug的擁護者－跟進bug以了解bug是否被定位這是你的工作。你寫報告的方法影響著軟件的行為是否會被更改，文檔是否會被更改為和現實的行為相匹配，或者是錯誤被忽視。許多沒有提倡使用精確操作過程的bug report，同樣也是很容易被忽視的。思考這份簡短的bug report：“當我用沒有帶任何參數的命令行啟動軟件時，我得到了一個“錯誤文件名”的錯誤，同時應用程序也中止了”。
寫這個報告的測試人員是希望沒有指定帶參數的命令行有一個特定的默認行為嗎？或是測試人員希望文檔能夠更好地解釋為什么至少要給予命令行一個參數？或者是她只是希望要一個更好的錯誤信息呢？可能她并不在乎要修復成什么樣，只是要一個用戶清楚并且行為和文檔相匹配的結果？讓我們看看四種能夠集中提高修改上面的bug report的機會方法。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
