目錄
業界/團隊內部普遍已經有的共識
- bug的預防/避免 優先於 bug的發現；
- BUG越早發現的越好
- bug給之後上線帶來不同程度的風險
- bug儘可能扼殺在上線之前，不然上線後很可能帶來線上問題
總之：BUG越早發現的越好，爲了證明這個論點，還可以從不同時期bug修復代價入手。
業界幾種評估不同時期bug修復代價的方法
一、修復的時間
開發人員自測/前後端聯調時發現(30s~5min)
開發人員邏輯思維思維嚴謹，異常處理得當，測試時通過(30s~5min)
測試人員測試、反覆重現並儘可能確定bug的場景，還要 抓日誌並填寫流程（5~20min）
開發人員根據提出的bug：
理解bug(30s~2min)
修復問題(5min)
重新發布(2~20min)
測試人員測試(1~5min)
不太順利的情況下，增加的時間：
開發人員重現不了bug，拉QA一起重新復現一遍（創造某種特定場景，問題演示、日誌抓取，接口返回等）(2~10min)
開發人員懷疑是操作步驟不對、環境不對等等原因，讓QA重新操作幾次/重置環境後重試(比如重新下載測試APP後重試)
bugfix後，QA重新驗證後，發現問題仍然存在(重複上述過程)；
bugfix時，不小心引入了新的問題(重複上述過程)
二、修復時測試的次數
一輪測試中：
測試的次數越多，QA時間越緊迫，越疲勞
開發人員自測/前後端聯調時發現(1次~2次)
開發人員邏輯思維思維嚴謹，異常處理得當，測試時通過(2次)
測試人員測試、反覆重現並儘可能確定bug的場景，還要 抓日誌並填寫流程（0~2次，爲了截圖、攔截日誌，重新復現問題）
開發人員根據提出的bug：
理解bug(0~1次)
修復問題(1次)
重新發布(0次)
測試人員測試(2次~5次)
不太順利的情況下，增加的時間：
開發人員重現不了bug，拉QA一起重新復現一遍（創造某種特定場景，問題演示、日誌抓取，接口返回等）(1~2次)
開發人員懷疑是操作步驟不對、環境不對等等原因，讓QA重新操作幾次/重置環境後重試(比如重新下載測試APP後重試)(1~4次)
bugfix後，QA重新驗證後，發現問題仍然存在(重複上述過程)；
bugfix時，不小心引入了新的問題(重複上述過程)
三、修復花費的費用
《Google如何測試軟件 —— 幫我像Google一樣測試》
下面的數據是Google提供的樣例成本,表示的是在不同的測試階段發現bug並進行修復所需要的成本。這些數據清楚地說明:在開發過程中越早發現問題,修復這些問題所耗費的成本越低。
ps: 下一個階段修復的代價是上一個階段修復代價的10倍
四、修復對上線的風險
一般來說，除非重大問題會推遲上線，一般雖然線下會發現大量bug，儘管風險會不同程度存在，但一般都會如期上線。
這裏暗含的意思有：
雖然明知道線下質量不是太高(這個可以通過線下的bug數量和嚴重級別看出來)，但90%+仍然會帶着風險上線；
帶着風險是指：由於線下問題太多，QA疲憊的忙於各種測試，迴歸，驗收；越忙時間越短可能思路越短缺，極容易遺漏“顯而易見”的問題。
bug暴露的方法探討
ps: bug的預防方法衆多，不同的業務也有不同的具體實施步驟，這裏不做逐一介紹了。這裏僅就bug暴露方面說一下自己的思考和經驗吧。
- 相比模塊/集成測試，代碼review和單元測試更容易發現某些類型的問題
實際的例子：
迴歸場景-某個底層方法的修改，例如：影響了登錄的用戶賬號，這種情況在實際的項目操作中，開發人員往往說自己修改了什麼方法，影響了XXX登錄，需要回歸下；這時QA人員也會儘可能全面迴歸，但仍然有遺漏。
做法需要重新回到更全面的需要上來，比如當時要求用戶賬號必須是什麼格式，有無特殊字符，具體的限制是什麼？
經驗參考： 根據業務具體特點，發現這類的典型測試場景，通過代碼review和單元測試進行覆蓋
- 不要把bug暴露壓力完全放在QA肩膀上
實際的例子：
一次故障覆盤會議上，大家針對爲什麼測試沒有發現，對QA“開撕”；或者針對代碼爲什麼這麼實現，對開發“開撕”
經驗參考：總和綜合考慮不同測試深度和廣度需要，將產品人員、開發人員、團隊其他成員拉進來，一起進行bug暴露。因爲任何人都可能犯錯/遺漏，如果bug暴露僅僅是QA的話，勢必不會100%保證bug的充分暴露了。
總結
通過計算不同時間段，修復問題的代價？ 成本？，並將此同步給團隊其他成員，可以在團隊內部，達到更好的對質量保證、bug暴露的共識和支持。反觀項目每次迭代中的bug分佈，bug數量，根源分佈等等手段，並將此同步給團隊其他成員，從而讓QA的工作增加更多的認同。