微軟內部開始實驗的新 QA 機制：Bug Goal

這個月初去微軟位於南港的創新中心（Microsoft Innovation Center, MIC）上課，
在第三天的課程中聽到一個很有趣的觀念，叫做 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 偷偷把功能簡化，所以程式變得很簡單，不容易出錯？

會影響 Bug Goal 的因素包括：

• 功能的複雜度
• dev 的熟練度
• tester 的熟練度
• 需求變化的程度
• ...（可能還有很多其他的因素，總之是要綜合考量這些因素）

有一點要強調的是，tester 找到的 bug count 有沒有 meet Bug Goal 絕對不是一個適合用來衡量 tester 能力的指標，例如 bug 的品質就是一項重要的因素（有沒有濫竽充數？），而有經驗的 tester 在 system design 的階段就會密切參與討論，貢獻自己的專業知識，提高系統的 testability，以及避免可能很難測試的設計，這些都可能造成 bug count 的降低，自然就達不到預先設定的 Bug Goal。

反過來說，達不到 Bug Goal 可以看成是一個好現象（前提是沒有人掩耳盜鈴），而且整個 team 長遠的目標應該是要讓 Bug Goal 越來越低，這表示 team member 的成熟度很高，可以產出高品質的 code。（這當然是個非常遙遠的理想）