一篇文章講清楚如何對軟件缺陷進行管理(3)

代價太大

正規的軟件公司會引入QA，對項目整個過程進行全方位的質量保證工作。但是執行QA需要調用很多的資源，比如要檢查和復審需求階段輸出的標準工件，就需要高水平的分析員加入，但是通常他們時間很少很寶貴，并且不會有太多的精力顧及此事。

在設計和實現階段，隨著大量審查工作的介入，所有該階段的參與人員都要付出更多的時間和精力來參與。

這些形式的檢查、審查和測試延長了整個項目的開發過程，這些附加的工作時間都會直接變成附加費用，大大增加了整個項目的造價。

市場決策

即使測試人員發現了產品中的BUG，但是公司會覺得修復BUG將延長整個產品的發布時間，有可能錯過銷售的旺季（可能是每年的5-10月份），并且會打亂整個公司針對該產品的銷售計劃，在確認產品中的BUG不是非常嚴重的情況下，軟件被銷售了。但是，如果這是航天、醫療、股票交易的管控軟件系統，如帶有BUG，則發布后果是非常嚴重的，但是對于某些行業這樣的做法是可行的。

時間緊迫

測試要花費大量的時間，至今尚未有一種自動化的測試工具能夠全面和高效率地測試一套軟件產品。

測試項目經理接到測試任務后表現得過于樂觀，沒有考慮任務的風險。

開發人員過高估計自己的能力，認為所有的BUG都是微不足道、便于修復的。他讓測試工作和編碼工作同時進行，這樣根本沒辦法保證測試的正確性。并且在時間緊迫的時候，大多數測試員只是選擇明顯的幾條程序路徑測試或者輸入不完整的測試數據，這些都造成了大量的BUG紕漏。

現場證據

有時會遇到這種問題，發現了BUG但是不知道怎么把它明顯地表示出來。不能向開發人員提供足夠的證據報告，是測試人員的恥辱，開發人員同樣會根據這樣的報告譏笑測試人員的所作所為。

BUG的可重現性，與導致BUG出現的原因有著密切的聯系。

BUG的可重現性也體現了測試人員對軟件系統的熟悉程度。

BUG的可重現性，也體現在操作的順序上。

過于自信

開發人員是非常不誠懇的測試人員，他們總是說“我做的肯定沒問題”或者“不可能呀，它在我的機器上跑得好好的”。有的時候項目管理者也很自負，過于相信團隊成員的表現，而不去理會測試人員或者客戶的抱怨。

Titanic災難就充分體現了人類的自信，我們有足夠的水密艙就算破了5個船也不會沉。

沒有詳細的測試計劃，沒有嚴謹的測試行為，不再關注每個細小的環節，這樣BUG就從旁邊悄悄溜走了。

原文轉自：http://www.uml.org.cn/Test/201611161.asp