在軟件開發過程中，有幾條準則是已經被無數次驗證的。
1、在項目發布后發現和修復Bug的成本是需求和設計階段所需的一百倍!
2、80%可避免的重復勞動源自于20%的缺陷，其中兩大主要來源包括草率的需求定制和象征性的案例
設計和開發。
3、大約80%的缺陷來自20%的模塊，而約半數的模塊是幾乎沒有缺陷。
4、90%的軟件的停工期最多來自于10%的缺陷。
上面四條原則說明了兩個問題，一是錯誤越早發現成本越低，而且大部分的錯誤都是在軟件開發的前面階段引入的。二是大部分的錯誤都集中在少數的模塊。
測試作為最有效的“馬后炮”，一直被認為最有效的保證軟件質量的手段。果真那么有效果嗎?首先得考慮一下這個問題：“為什么80%的缺陷會在20%的模塊，而過半數的模塊幾乎沒有缺陷呢?”。
缺陷集中出現有兩種可能，一是大量出現缺陷的模塊特別復雜，以至于軟件設計者和程序員沒有能力保證程序沒有錯誤。二是編寫這些模塊的程序員比編寫其他模塊的程序員水平要低，或者做事情要毛糙。第一種可能是可以避免的，如果模塊太復雜就將其分解為若干更小的模塊，直道劃分的模塊夠簡單為止，這也是模塊劃分過程中應該要做的。核心技術應該由骨干人員進行技術攻關，保證其正確無誤的實現。至今也沒有聽說過有程序員實現不了的軟件，程序員、特別是優秀的軟件設計師的能力無需懷疑的。那么問題出現在編寫程序的程序員的水平有高低，或者質量意識不夠強。10個程序員中如果9個編寫的程序都沒有問題，另外1個人水平欠缺就可能導致問題都出現在他編寫模塊中。
等到軟件編碼完成后，進行測試的時候發現了問題，這個時候再去改正，那么錯誤修正費用已經發生了。何不一開始就替換掉能力低下的程序員，或者干脆少了這兩個程序員而延長項目開發時間來保證軟件的質量呢?測試雖然能夠發現問題，卻不能節約成本。
將測試引入到需求分析階段，將需求的問題，在需求分析階段就找出來。這樣就可以節約100倍修復開銷，這樣的只賺不賠的事情為什么不做呢?
軟件質量靠的不僅是測試，而是軟件企業對軟件質量的關注程度，如果一開始就將質量放到一個比較高的位置，我想測試這種“馬后炮”才能夠更充分的發揮它的作用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/