自由軟體開發者simon tatham針對如何有效地報告bug發表了自己的看法，他列舉了一系列拙劣bug報告的例子，並提出了改正建議。
simon首先列舉了一系列拙劣bug報告的例子，包括：
· 在報告中說「不好用」；
· 所報告內容毫無意義；
· 在報告中使用者沒有提供足夠的資訊；
· 在報告中提供了錯誤資訊；
· 所報告的問題是由於使用者的過失而產生的；
· 所報告的問題是由於其他程式的錯誤而產生的；
· 所報告的問題是由於網路錯誤而產生的；
接著，他點出了報告bug的目的：
在bug報告裡，要設法搞清什麼是事實（例如：「我在電腦旁」和「xx出現了」）什麼是推測（例如：「我想問題可能是出在……」）。如果願意的話，您可以省去推測，但是千萬別省略事實。
然後，simon針對bug報告的不同問題分別提出了自己的見解：
「程式不好用」
程式設計師不是弱智：如果程式一點都不好用，他們不可能不知道。他們不知道一定是因為程式在他們看來工作得很正常。所以，或者是您作過一些與他們不同的操作，或者是您的環境與他們不同。他們需要資訊，報告bug也是為了提供資訊。資訊總是越多越好。
許多程式，特別是自由軟體，會公布乙個「已知bug列表」。如果您找到的bug在列表裡已經有了，那就不必再報告了，但是如果您認為自己掌握的資訊比列表中的豐富，那無論如何也要與程式設計師聯絡。您提供的資訊可能會使他們更簡單地修復bug。
「演示給我看」
報告bug的最好的方法之一是「演示」給程式設計師看。讓程式設計師站在電腦前，執行他們的程式，指出程式的錯誤。讓他們看著您啟動電腦、執行程式、如何進行操作以及程式對您的輸入有何反應。
他們對自己寫的軟體瞭如指掌，他們知道哪些地方不會出問題，而哪些地方最可能出問題。他們本能地知道應該注意什麼。在程式真的出錯之前，他們可能已經注意到某些地方不對勁，這些都會給他們一些線索。他們會觀察程式測試中的每乙個細節，並且選出他們認為有用的資訊。
這些可能還不夠。也許他們覺得還需要更多的資訊，會請您重複剛才的操作。他們可能在這期間需要與您交流一下，以便在他們需要的時候讓bug重新出現。他們可能會改變一些操作，看看這個錯誤的產生是個別問題還是相關的一類問題。如果您不走運，他們可能需要坐下來，拿出一堆開發工具，花上幾個小時來好好地研究一下。但是最重要的是在程式出錯的時候讓程式設計師在電腦旁。一旦他們看到了問題，他們通常會找到原因並開始試著修改。
「哪兒出錯了？在我看來一切正常哦！」
如果您給了程式設計師一長串輸入和指令，他們執行以後沒有出現錯誤，那是因為您沒有給他們足夠的資訊，可能錯誤不是在每台計算機上都出現，您的系統可能和他們的在某些地方不一樣。有時候程式的行為可能和您預想的不一樣，這也許是誤會，但是您會認為程式出錯了，程式設計師卻認為這是對的。
同樣也要描述發生了什麼。精確的描述您看到了什麼。告訴他們為什麼您覺得自己所看到的是錯誤的，最好再告訴他們，您認為自己應該看到什麼。如果您只是說：「程式出錯了」，那您很可能漏掉了非常重要的資訊。
如果您看到了錯誤訊息，一定要仔細、準確的告訴程式設計師，這確實很重要。在這種情況下，程式設計師只要修正錯誤，而不用去找錯誤。他們需要知道是什麼出問題了，系統所報的錯誤訊息正好幫助了他們。如果您沒有更好的方法記住這些訊息，就把它們寫下來。只報告「程式出了乙個錯」是毫無意義的，除非您把錯誤訊息一塊報上來。
特殊情況下，如果有錯誤訊息號，一定要把這些號碼告訴程式設計師。不要以為您看不出任何意義，它就沒有意義。錯誤訊息號包含了能被程式設計師讀懂的各種資訊，並且很有可能包含重要的線索。給錯誤訊息編號是因為用語言描述計算機錯誤常常令人費解。用這種方式告訴您錯誤的所在是乙個最好的辦法。
在這種情形下，程式設計師的排錯工作會十分高效。他們不知道發生了什麼，也不可能到現場去觀察，所以他們一直在搜尋有價值的線索。錯誤訊息、錯誤訊息號以及一些莫名其妙的延遲，都是很重要的線索，就像辦案時的指紋一樣重要，儲存好。
如果您使用unix系統，程式可能會產生乙個核心輸出（coredump）。核心輸出是特別有用的線索**，別扔了它們。另一方面，大多數程式設計師不喜歡收到含有大量核心輸出檔案的email，所以在發郵件之前最好先問一下。還有一點要注意：核心輸出檔案記錄了完整的程式狀態，也就是說任何秘密（可能當時程式正在處理一些私人資訊或秘密資料）都可能包含在核心輸出檔案裡。
除此之外，simon還舉了其他一些例子，他最後總結到：
·bug報告的首要目的是讓程式設計師親眼看到錯誤。如果您不能親自做給他們看，給他們能使程式出錯的詳細的操作步驟。
·如果首要目的不能達成，程式設計師不能看到程式出錯。這就需要bug報告的第二個目的來描述程式的什麼地方出毛病了。詳細的描述每一件事情：您看到了什麼，您想看到什麼，把錯誤訊息記下來，尤其是「錯誤訊息號」。
·當您的計算機做了什麼您料想不到的事，不要動！在您平靜下來之前什麼都別做。不要做您認為不安全的事。
·盡量試著自己「診斷」程式出錯的原因（如果您認為自己可以的話）。即使做出了「診斷」，您仍然應該報告「症狀」。
·如果程式設計師需要，請準備好額外的資訊。如果他們不需要，就不會問您要。他們不會故意為難自己。您手頭上一定要有程式的版本號，它很可能是必需品。
·表述清楚，確保您的意思不能被曲解。
·總的來說，最重要的是要做到精確。程式設計師喜歡精確。
如何有效地報告Bug？
simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 例如 我在電腦旁 和 xx出現了 什麼是推測 例如 我想問題可能是出在 如果願意的話，您可以省去推測，但是千萬別省略事實。然後，simon針對bug報告的不同問題分別提出了自己...
如何有效地報告Bug？
作者 崔康 發布於 十月 08,2012 自由軟體開發者simon tatham針對如何有效地報告bug發表了自己的看法，他列舉了一系列拙劣bug報告的例子，並提出了改正建議。simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 ...
乾貨 如何有效地報告 Bug
拙劣的bug 電腦程式 中的錯誤或程式執行時的瑕疵 譯者注 報告例子 技術支援 很可怕的工作？因為有拙劣的bug報告需要處理。好的bug報告的特性 非常清晰 有幫助並且 有內容 報告bug的最好的方法之一是 演示 給程式設計師看。讓程式設計師站在電腦前，執行他們的程式，指出程式的錯誤。讓他們看著您啟...