案例：
某軟件公司在開發一個城鎮居民保險系統時，在單元測試、集成測試階段，為了追趕進度，開發人員與測試人員都沒有介入測試工作。
系統測試階段，測試小組借助缺陷管理工具和開發人員交互進行測試與缺陷修復工作。期間，發現“扭轉文檔無法歸檔”的嚴重錯誤，開發人員在修改時，認為難度太大，決定暫停修改，得到測試人員認可。在產品發布前，該問題在開發環境下得到解決。
回歸測試結束后，開發人員把開發環境下的產品打包，發送給客戶。
分析：
在案例中，有幾處顯然不合理的地方：
測試介入太晚
回歸測試做得不合理：“開發人員把開發環境下的產品打包，發送給客戶”，明顯還缺少一次測試。所有的缺陷應該經過驗證修改后才可以發布產品。
產品發布的出口不對：案例中的產品最后由開發人員直接發布，十分不合理。很多缺陷在開發環境下運行時不會出現，來源于開發環境打包的產品隱藏更多的缺陷。實際最后發布的產品應該從產品庫中提取，而且基線庫中的產品應該是最后經過測試的。
缺陷流程管理不合理：
缺陷的權限控制不嚴：開發工程師無權決定是否延期或者暫時停止修改某一缺陷;測試工程師認可錯誤的決定也是不合理的。
沒有對每個缺陷進行全程跟蹤：測試工程師應該跟蹤每一條缺陷，并確定修改后才可以進行關閉操作，而不是發現缺陷就完成了任務。軟件測試
缺少缺陷審核步驟：產品發布前，項目經理應該對產品發現的缺陷進行審核，根據修改狀況決定是否可以發布。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
