這是一個典型的Bug跟蹤過程，設計者篤信只有完整的檢查才會保證修改一個Bug的時候不會產生另外一個Bug。但是現實好像總是跟他作對，Bug返回率一直居高不下。于是設計者修訂了流程，增加了幾個步驟。他希望問題能夠通過復查被發(fā)現出來。但是增加了流程以后Bug返回率反而提高了。
“這是人的問題！”流程設計者認為。
這不是人的問題，這是流程的問題。我說。
另外一個團隊，并沒有采用這樣的模型，Bug返回率卻很低，而且修改的時間明顯的要短于前一個團隊。他們采用的是這個流程：
這個流程和前一個流程的最大區(qū)別在于測試是自動進行的，而且由開發(fā)團隊自己進行管理。這是開發(fā)團隊的內部流程，由測試團隊提出的Bug，將會被首先整理成一組測試用例來進行復現，自動測試中的代碼可以自由修改，所以，問題定位要快的多，并且修改了代碼以后，可以馬上對測試用例進行回歸測試。很快就可以知道是否修改完畢。并且，對于有影響的模塊，由于已經有了大量的測試用例，可以全部回歸，從而避免了因為影響性分析不充分而造成的Bug返回，所以大大的降低了Bug的返回率。
我們?yōu)橐患掖笮碗娦殴咀鲎稍兊臅r候，他們采用了比圖1更加復雜的流程，還有上傳修改代碼和確認的過程，但是效果沒有得到改善，而且所耗時間更長。在采用了我們幫助其完善的新流程以后，Bug修改時間和效果上都得到了大大的改善。
注：Bug返回率是指，開發(fā)團隊將修改后的代碼提交給測試團隊以后，測試團隊驗證Bug修改狀況，對于沒有修改正確的Bug返回到開發(fā)團隊的情況稱作返回。返回個數占修改個數的比例稱作Bug返回率。