在第三天的課程中聽到一個很有趣的觀念，叫做 Bug Goal，以下就來說說這是什麼。
在上一篇文章：微軟的組織架構 ＆ Developer 的工作態度中曾經提到，基本上每個微軟的 team 都是由 PM、dev、以及 tester 組成，而 Bug Goal 就是由 Tester 這邊提出來的新觀念，目前正在美國總部小規模實驗中，如果成效良好，可能會全面推廣。
顧名思義，Bug Goal 指的是 bug 的指標，更清楚一點的說，是指在每個功能區塊中預期會產生多少 bug。一開始聽到這個觀念大家都覺得不可思議，所以花了不少時間討論。
Bug Goal 一開始大概只能靠 manager 從過去的經驗中做一個接近直覺的估計，但是隨著經驗的累積，理論上這個值應該愈來愈精準。訂定 Bug Goal 的目的如下：
- 激勵 tester 在程式中找出數量足夠的、有意義的 bug，目標就是 Bug Goal 設定的數量。
- 激勵 dev 寫出更高品質的 code，讓 tester 沒辦法抓出足夠的 bug 來達到 Bug Goal 設定的數量。
（有點像是故意在 dev 和 tester 之間建立一個良性的競賽，目的在提高品質） - 讓 PM 多了一種衡量程式品質的數據，當某一個功能根據過去的經驗，是很容易產生大量的 bug，但專案執行一段時間以後 tester 卻幾乎沒有找到任何 bug 的時候，就應該主動更深入的了解一下專案執行的狀況，當然有可能是程式的品質真的非常好，但有沒有可能是 teser 在偷懶？或者 dev 偷偷把功能簡化，所以程式變得很簡單，不容易出錯？
- 功能的複雜度
- dev 的熟練度
- tester 的熟練度
- 需求變化的程度
- ...（可能還有很多其他的因素，總之是要綜合考量這些因素）
反過來說，達不到 Bug Goal 可以看成是一個好現象（前提是沒有人掩耳盜鈴），而且整個 team 長遠的目標應該是要讓 Bug Goal 越來越低，這表示 team member 的成熟度很高，可以產出高品質的 code。（這當然是個非常遙遠的理想）
2 則留言:
Tim大,
請問有沒有提到衡量bug數量的Methodlogy？還有，bug的數量多並不代表嚴重，不是用量化就好，可能還是有牽扯到bug的嚴重程度，這部份又是怎麼定義的呢？
Hi Derek,
1. 我想只要被 tester 提報為 bug 就會被納入 bug 的總量中，應該沒有什麼特殊的 methodology。前陣子我在 InfoQ 上看到一篇不錯的文章：Throw Away Your Bug Tracking System? (http://www.infoq.com/news/2009/03/testobsessed-on-agile-bugs)，裡面有提到「誰有權力認定這是一個 bug？」，以及「到底什麼樣的錯誤才能算是 bug？」等等議題，蠻好看的（精華在原文裡面哦），你可以參考一下 :)
2. 你說的沒錯，bug 的量不是最重要的指標（上面那篇 InfoQ 的文章也有講到，不禁要再度推薦一下 XD），至於 bug 的嚴重程度的話，微軟內部也有大致區分成幾個等級，詳細的內容我有點忘了，總之是類似緊急、中等、普通之類的。但是 security 相關的 bug 是最最嚴重的，在產品 ship 之前絕對不能有已知的 security bug 尚未被修復，所以從 RC -> RTM 會做的修正多半與 security 有關。
另外在上課過程中講師也不斷強調，微軟是很客戶導向的，customer 的意見非常重要，只要是會對客戶有重大影響的（根據長久下來累積的 marketing 資料庫分析），嚴重度就會提高。
3. 關於提到 Bug Goal 這個概念的投影片，我放到 SkyDrive 了，請服用： http://cid-e25b289c2766addf.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/Great%20Docs/Microsoft%20Innovation%20Center%20Forum%202009.04/MicTw-2009-04%20-%20Is%20Your%20Product%20Ready%20To%20Release%20%7C5External%20Copy%7C6.pdf
張貼留言