Avery在一個與市場實際同步的公司當項目經理。由于受到限制，所以每個客戶都馬上要一個β版本，這樣他們可以盡快開始使用軟件�？紤]到一個有著許多缺陷的β版本將使他們的客戶憤怒，Avery認為，讓開發人員在系統測試之前就開始查找和修復嚴重缺陷是更節省成本并且是低風險的。
兩個項目對于查找和修復缺陷使用兩種完全不同的方法。我們對于修復缺陷都有不同的看法，尤其是什么時候修復哪些缺陷。選擇是否修復缺陷取決于很多因素，如：開發的產品類型；攜帶已知或未知缺陷的風險；開發過程；當確定修復缺陷時，需要多少成本。
其中最容易理解的一個因素是修復一個缺陷的實際成本。這個成本反映到選擇的開發生命周期、開發過程，并幫助你在可以承受的風險內決定提交或不提交產品。然而，事實上很多人都不知道修復一個缺陷需要花費多少成本。如果你也沒有把握，那么這里有一個用來測量這項成本的估算方法。
在系統測試的時候，人們全身心投入于查找和修復缺陷，可以計算出缺陷的數量。你知道多少人（開發人員、測試人員以及其他任何人）在做這個項目，你也知道系統測試的持續時間。有了這些數據，你就可以計算出項目在這個階段修復一個缺陷的成本�？梢酝ㄟ^下面的公式計算查找和修復一個缺陷的平均成本。
修復一個缺陷的平均成本＝（人員數量×天數）×平均人日成本/修復的缺陷數量
注意：“發現”的缺陷數量不具備足夠的信息，而應該使用“修復”的缺陷數量。發現缺陷只是第一個步驟。定位錯誤、決定如何修復、開發人員測試（又名單元測試）修復的內容、系統測試修復項、尋找由這個缺陷引起的其它缺陷，所有這些都是為什么使用“修復”數值是如此的重要。讓我們看一些例子。在這些例子中，我假設每人日成本是500美元。
Dan的項目在系統測試時，暴露了大量的缺陷，雖然大部分缺陷是容易修復的，但是還有一些缺陷需要花很長時間。Avery的項目在系統測試時暴露出非常少的缺陷，但是由于發現每個缺陷的時間間隔是如此的長，所以似乎是花很長時間在修復一個缺陷。使用上面提到的計算公式，表1是Dan和Avery項目系統測試的數據。
只要你回顧一下項目的整個框架，就可以看出這項度量對系統測試修復缺陷成本的估算是有益的。但是，我們注意到Avery項目的修復成本是很高的。實際上，Avery的項目是以非常低的讓客戶失望的風險到達β發布日期（在系統測試的20個工作日）。Dan的項目花了兩個月（40個工作日）的測試時間，雖然修復了125個缺陷，但是他們仍然有超過300個的缺陷沒有修復。因為Dan的團隊在系統測試前很努力地在預防缺陷，所以Avery的項目是節省成本的。因為Avery的團隊預先發現并修復了大部分的缺陷，所以實際上使用上面的估算技術，他們修復缺陷的成本在系統測試中被大大放大。因為Avery的項目在系統測試之前發現并修復了大部分的缺陷，所以上述估算技術是不合理的。Avery項目能夠用計算出實際查找和修復缺陷的成本來代替估算值。Avery平均使用了8個小時的系統測試時間來查找和修復一個缺陷。表2是對Avery系統測試成本更實際的估算。
使用更新后的數據，表3是一張Dan和Avery項目修復一個缺陷所需成本的更清晰的圖表。
因為Avery的項目查找缺陷比修復缺陷花費了更多的時間，所以Avery有高的系統測試成本。雖然如此，Avery這個較大的項目的總缺陷修復成本比Dan這個較小的項目低。并且Avery的修復缺陷的版本發布成本比Dan的項目低許多。
因為成本不僅取決于在項目里執行的活動和什么時候開始跟蹤缺陷，也取決于修復缺陷上的花費，所以每個項目有它自己修復一個缺陷的成本。你可以使用修復成本來決定如何繼續這個項目或進行下一個項目。如果你的成本太高，而且你還沒有在系統測試階段，那么可以嘗試一些缺陷發現和預防技術。如果每個人一起查找和修復缺陷，那么不僅僅只計算修復時間，也計算了查找缺陷的時間。
如果你在系統測試階段的查找和修復缺陷的成本很高，那么發布初期的風險是什么?Avery可能在查找和修復缺陷成本為3333美元時選擇早一些結束系統測試并早一些發布，同時他知道項目版本發布成本將上升。只有Avery和他的管理部門能夠評估發布初期的風險。
可以使用發布前的修復成本來了解你和你的職員在項目發布前的活動是否有成本效益。我發現每個組織不緊密依賴于項目而有各自特定的版本發布成本。因而我使用版本發布成本來幫助定義發布標準。這幫助你管理在發布后有太多缺陷需要修復的風險。
了解查找和修復一個缺陷需多少成本使得你可以對查找、修復、驗證缺陷的過程提出疑問。這是使用合適質量建立一個系統的另一個方法.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
