每次項目結束，都會發現有一堆的Bug。如何分析這些Bug，避免重蹈覆轍。
有兩種分析方法， 根據Developer在修復Bug時選擇的CommonCause，選擇比重最大的CommonCause，
然后從各個方面分析RootcCause。總結出可以改進的地方。
我很難理解這種方法，主要是覺得每次都是泛泛而談，對減少BUG沒有真正的幫助。
(我確信這種分析方法沒有太大的意義,因為缺乏對底層原因的了解. 而且Developer在選擇common Cause的時候完全可能沒有合適的而任選一個.經常看到的一個例子是缺乏UT. 這個就不一定是真正的原因,事實往往是做了UT卻沒有發現出Bug.這種分析方法是典型的不深入實際的浮夸作風, 依賴統計的數據而沒有看到統計數據事實上可能存在問題. 這樣的工作肯定效率不高. )
下面是我的一些思考。
分析的基礎應該是Bug，而不是commonCause。直接從CommonCause開始分析，至少可能遺漏一下重要有價值的發現。
有些Bug是有可能避免的。而有些bug可以說沒有什么好的對策。我們應該集中分析有可能避免的Bug。
至于如何分析具體Bug是否能避免，首先應該是造成該Bug的Developer自己分析，讓大家知道Bug是如何形成的，然后由大家集體決定。（這樣做的風險是大家能否接受。）
其次根據Bug引入的時間，和最終測試出的時間，總結有沒有可以改進的大方。
能夠由developer改進而消除的Bug。是最有希望避免再次發生的。
比如，有些bug是打字錯誤造成界面上顯示的內容有瑕疵，一個可行的改進是每次都從需求文檔拷貝。
注意必須要有措施能保證該經驗能被所有Developer知道。
另一個例子是，我有一次，是的，我有一次再修正bug是沒有清除徹底。在總結的時候我掌握了全局查找、替換的技巧。有效地避免了類似的錯誤再次發生。
并非所有錯誤都能由devloper來消除，有一些只能由Tester來消除。比如，一般來說，Tester總是比Developer對界面敏感，更能發現界面bug。
我覺得隨著單元測試的進步，現在對Developer的測試水平的要求也提高了。這也許不盡合理。developer對實現花了很多精力，他不可能在測試上達到同樣的水準。