你有沒有為了要更多的信息而被返回bug report的經歷呢？有沒有碰到過你發現的一個非常嚴重的錯誤被推遲到下一個版本才去修復的情況呢？
?
????? 你提交的每一個bug report都是和項目組就正在測試中的軟件質量問題的一種書面溝通方式。通常，你用于溝通程序錯誤的能力－不是體現在錯誤本身的內在嚴重程度－而是體現在確定這個錯誤是否需要修復。
?????? 如果這是一個可怕的想法，你可能會想，“等等！我討厭寫作，我并不擅長寫作。怎么樣才能夠通過編寫bug report來決定錯誤的命運呢？”它要吸引大家相信錯誤是為他們說話的－任何一個頭腦正常的人都應該主動地查看一個特定的錯誤是足夠可怕的以致要被修復。不幸的是，事實并不是這樣。
?????? 但是好消息是：有效的和軟件開發人員、項目組溝通的能力不是由你在高校英語課程中的表現所決定的。
?????? 這不是關于用有趣的詞語編寫流暢散文，也不是關于優秀語法和拼寫的方法。它是有關僅用能夠表達你觀點的詞語明白地表述錯誤的方法。太多地話將會使你的觀點陷入茫然無措中。太少地話又會使他人用自己的假設去填補隔閡－通常是對軟件有害的部分。如果你不是很確信是什么樣的錯誤，那么不管你的bug report寫得怎么好，也沒有人知道那是什么樣的錯誤。
?????? 這篇文章主要討論你現在能夠開始著手提高人們傾聽你發現的錯誤的機會的4個方法。
了解你的聽眾
?????? 毋庸置疑，任何寫作課都會告訴你必須了解你是為誰編寫bug report。
?????? 每份bug report至少有兩個聽眾：必須要修復錯誤的人和決定錯誤命運的人或團體。有時一個人會同時負責這兩份工作，但是仍然是兩個不同的聽眾，只是一起發生在同一個人身上罷了。
?????? 你的第一個聽眾－那個必須修復錯誤的人需要清楚，明確的步驟以重現錯誤。信息越多越好。針對這個目的，我們稱這個人為“開發人員”。開發人員需要關于我們操作了什么和我們看見了什么的準確信息。
?????? 你的第二個聽眾－決定錯誤命運的人或團體需要知道如果不修復此錯誤的后果。這個聽眾需要精練的語句以抓住他們的注意力并且引發對錯誤的相關連問題的討論。基于這個目的，我們稱他為“錯誤審核委員會”。在使錯誤得以修復的過程中你的角色是幫助錯誤審核委員會了解不修復錯誤的風險遠遠超過修復錯誤可能發生的風險。
?????? 你越了解你的開發人員和錯誤審核委員會如何工作，你就越可以根據他們的需要裁減你的bug report。盡力在私底下設法了解你的聽眾。如果你能夠出席錯誤審核委員會會議，嘗試這樣做。你將學習到許多關于你的聽眾是如何思考的知識。
選擇一個好的標題
????? 一般把用于描述錯誤的短句稱為錯誤的標題或描述。這是bug report中最重要的部分。錯誤審核委員會成員經常通過它來決定錯誤是否可以推遲修復。如果標題沒有力度，委員會成員可能認為它是不值得花費太多的時間。（畢竟，在接下來的2個小時里還有145個以上的錯誤要審核。）
?????? 以下是一些示例：
好的：超時后在退出時崩潰了
太長的：在數據庫不可用后你又保存記錄的更改,然后從文件菜單中選擇退出時程序崩潰了
不足夠的信息：程序崩潰了
太模糊：當數據庫離線時出現問題
標題變成了一種給項目組提供檢查和調查錯誤的方法。和數據相比，人們更容易記詞語。人們更愿意記得“在windows2000下不能夠安裝”的錯誤，而不是類似“＃23423”錯誤，而且在以后人們還會利用這些關鍵詞搜索錯誤。
????? 編寫一個好的，簡明的錯誤標題是不容易的。和編寫bug report的其他部分相比，應該多花些時間構造理想的錯誤標題。要確信標題是足夠短以便能夠在顯示錯誤的屏幕上和由缺陷跟蹤系統生成的報表中顯示完全（不會折行）。標題不必是完美的語法，而應簡短并一針見血。
書寫清楚，明確的步驟
?????? 你提交給開發人員的步驟應該提供如何產生錯誤的信息，這樣錯誤就能夠被發現并且修復。它也需要給錯誤審核委員會提供錯誤發生的環境。
唯一正確：
1．? 運行客戶端
2．? 找出一個記錄
3．? 更改記錄但不存盤
4．? 使數據庫服務器脫機
5．? 嘗試保存記錄
6．? 收到一個超時的錯誤
7．? 退出客戶端
結果：崩潰
馬虎的（有很大空間讓人產生誤解的）：
使數據庫服務器脫機，保存，然后退出，崩潰了。
太多冗余的信息（不能夠指出什么是引發錯誤的最關鍵原因）
1．? 運行客戶端
2．? 為輸入新的條目查詢數據庫
3．? 打開一個瀏覽器
4．? 在yahoo.com上瀏覽新聞
5．? 關閉瀏覽器
6．? 選擇一個條目
7．? 把種類從“蔬菜” 更改到“水果”
8．? 使數據庫服務器脫機
9．? 嘗試保存記錄
10．?????????????????????? 收到一個超時的錯誤
11．?????????????????????? 退出客戶端
結果：崩潰
在這個例子中，測試人員記錄在發現錯誤之前他所作的一切，但是他沒有檢查是不是每個步驟都是必要的，例如從yahoo.com閱讀新聞。
如果你只寫下那些產生錯誤必不可少的步驟，開發人員將很少告訴你他們不能夠重現錯誤，同樣錯誤什么委員會也會很少決定“沒有人將會做到那個程度！”
但是如果每個步驟都是必須的，怎么辦呢？如果錯誤只在你執行了一些看上去沒有關系的步驟后出現了，那么在bug report中記錄下這些步驟。你可以在那些看上去沒有邏輯關系的步驟后寫上“必須的步驟”，或者你可以在bug report的開始部分加上注釋：“注意－這里的每一個步驟都是重現錯誤的必要步驟。
編寫清晰的步驟同樣可以在驗證修復過程中提供幫助，特別是在另一個測試人員做驗證的時候。
解釋錯誤的影響，不只是癥狀
一些bug report是令人誤解的。從錯誤的表層看是無傷大雅的，但是如果在你檢查錯誤的牽連時，你發現它是一個非常嚴重的問題。如果你在錯誤審核委員會，你會擁護先修改哪一個錯誤呢？
1．? 關于“一個令人討厭的對話框阻止關閉應用程序”的報告
2．? 關于“在退出時應用程序中止了” 的報告
這兩個是同一個錯誤。差異完全在于測試人員如何編寫bug report。
在此提到的“令人討厭的對話框”是指Windows操作系統中顯示不能退出進程的窗口（“這個Windows應用程序不能響應結束任務的請求。。。”）。測試人員在試圖關閉機器而不是退出應用程序時發現這個問題。應用程序沒有等待來自用戶的輸入，因此退出失敗是沒有原因的。實際上，這個癥狀指出了更深的問題－在第一個關于“令人討厭的對話框”的bug report被推遲修復時幾乎要遺漏的問題。
這個 “令人討厭的對話框”的bug report存在著兩個問題。首先，它不精確。如果測試人員在步驟中包括了“令人討厭的對話框”中的文字，決策者可以認識到對話框是一個嚴重的問題而不是一個微小的干擾。第二，這份報告沒有指出錯誤的其他隱藏的問題：應用程序被中止了。
結論
我們都想把自己的工作變得與眾不同。我們想知道是因為我們努力的工作而使得軟件的最終版本更好。我們用來溝通錯誤的能力在我們是否有盡我們希望多地影響軟件的最終版本中是決定因素。
因此當你編寫bug report時，記住你的聽眾，選擇一個好的標題，清楚的記錄步驟并解釋錯誤的影響。你的bug report將會因為你花在它上面的格外努力而更好，并且有更多的錯誤被修復。最終將達到我們期望的結果－使錯誤在傷害用戶之前得到修復。