-
原文網址： Why bugs don't get fixed
作者：Alan Page， 微軟卓越測驗工程總監，How We Test Software at Microsoft (中文翻譯為《微軟的軟體測試之道》)一書的作者之一。
翻譯：盧玥儷、陸夢嫣、汪宏
近來我遇到越來越多的人對我們會發布還有bug的產品感到驚訝。而讓我大吃一驚的是，這些人中還有許多是軟體測試人員，我以為他們應該對此早已經有所了解。建議大家先閱讀Eric Sink較早寫的（但很棒的）文章。我不知道我還能對此話題有多少貢獻，但我想試試看。
許多bug並不值得去修復。 「你這也算是測試人員嗎？”，你肯定會沖我大叫，“測試人員是產品質量的捍衛者。”我可以再重複一次（如果需要的話）許多bug並不值得去修復。 「讓我來告訴你原因。在大多數情況下，修復bug就必須要修改程式碼。而修改程式碼需要投入資源（時間）並會引入風險。這真是很糟糕，但這卻是事實。有時，如果風險和投入遠超過修復bug的價值，因此我們就不會被修復這些bug。
我們決定是否修復一個bug並不是，也不應該是靠「感覺」。我喜歡用「使用者痛苦」的概念來幫助我做決定。我會用三個關鍵因素來考慮並確定「使用者痛苦」：
1.嚴重性—— 這個bug將產生什麼影響—— 它會讓整個程式崩潰嗎？它會導致用戶的資訊遺失嗎？或者並不是那麼嚴重？有更簡單的解決方法嗎？還是它只是個無關緊要的問題？
2.頻繁性－ 使用者碰到這個問題的頻率高嗎？它是程式主要工作流程的一部分？還是隱藏在一個不常用的功能中？在最常用的那部分程式中存在的小問題很可能是需要修復的，而一些不常用到的那部分程式中存在的大問題，也許我們會放在一邊。
3.對客戶的影響－如果你之前準備工作做得好，你應該已經知道你的客戶是誰，你的每個客戶群中會有多少（或者是你希望有多少）用戶。這樣你就需要判斷，這個問題將會影響每位用戶一，還是只是一部分人。如果你能追蹤客戶如何使用你的產品，你就能得到更精確的數據。
以上3點因素就構成了一個公式。給上面的每一個因素都分配一個數值範圍，並且用一些計算—— 你可以直接使用加法、乘法或是基於你的應用程式以及市場因素加上權值。打個比方，我們只需要執行加法並且對每個bug給予10分的數值範圍。
Bug #1：例如它是一個會讓程式崩潰的bug（10分），它存在於程式的主要部分（10分），它影響了80%的客戶（8分），因此這個bug的」用戶痛苦「量值為28分，我們打賭我們肯定會修復它。
Bug #2：它只是一個關於排列的bug（2分），它出現在二級視窗中（2分），這個bug所在的那部分程式只會在舊版本中被使用到（2分）。因此這個bug的「使用者痛苦」 量值為6分，我們很可能不會去修復它了。
遺憾的是，很多情況並不像上面所說的那麼簡單。 Bug #3是一個資料遺失問題（10分），它存在於一個應用程式的某個主要部分中，卻只在某些特定的情況下才出錯（5分）（順便提一下，資料是主觀編造出的）。客戶研究證明它很少會被使用（2分）。因此它的「用戶痛苦」量值為17分，這是一個模稜兩可的數據，修與不修都可以。一方面，修復它所需要的投入可能不值得，只要這個問題能夠被理解，而且它沒有任何盲點，不再理會這個bug很可能是正確的處理方法。
從另一方面來看，你必須把它和系統中的其他bug進行權衡。我們在這裡應用「破窗效應（Broken Window）」— 如果應用程式中有太多此類中等閾值的bug，產品的品質（或最起碼，從品質的感覺上）一定大受影響。你在考慮系統中每一個bug的時候，還應該結合考慮系統中其他（已知的）bug，並且以此來分析、決定哪些bug是需要被修復的而哪些則不值得被修復。
正式發布的軟體中有bug的確是一件十分糟糕的事—— 但基於我們現有的開發工具和開發語言，我們還沒有找到一個更合理的解決方法。
補充：
寫出這篇文章的時候，我想我遺漏了公式中的第四個因素：發布日期。在接近發布日期時，這個因素在修復/不修復bug的決定中也起了關鍵作用。然而我並不確定它是否是第四個因素，也無法確定在接近發布時期時，修復一個bug所需的「使用者痛苦」量值的閾值是多少。