「光是觀看，你就能觀察到很多。」——棒球名將尤吉・貝拉（Yogi Berra）
品質資訊不只來自跑程式#
軟體測試的工作是提供產品品質的相關資訊。許多人以為，取得這種資訊的唯一方法就是在電腦上執行軟體、或至少審查程式碼。但這種信念極度受限。
關於產品品質的資訊，永遠四處散落、唾手可得——只是僅有那些「在觀看、且能辨認出其相關性」的管理者才看得到。
作者把這類「關於資訊品質的資訊」稱為後設資訊（meta-information），並以妻子達妮（Dani）的狗訓練經驗開場：一位飼主抱怨喜樂蒂幼犬「老是在客廳地毯上大便」，達妮追問「還有其他行為問題嗎？」，飼主想了想說：「有，牠老愛抓前門、嗚嗚叫。」
我們很容易嘲笑別人看不出兩個「問題」之間的關聯（狗想出門、卻被迫在室內解決），但這種盲點正是「離問題太近、情感涉入太深」的人的典型。學會辨認這類免費資訊，是成功管理測試的祕訣之一。
十四個「喜樂蒂故事」#
作者接著列舉一連串諮詢案例，每一個都示範如何從一句話中萃取出後設資訊：
- 我們有規格，但找不到：測試經理說有用規格測試，卻不知道規格在哪，估計「找出來大概要一個月」。找不到關鍵文件，幾乎就是開發流程的「三振出局」
- bug 太多，bug 資料庫跑不動了：四萬行程式碼竟產生超過 14000 筆 bug 報告，測試經理卻把它當成「資料庫效能問題」，而非「開發流程問題」。最關鍵的線索是他毫無情緒地陳述這件事——流程一團糟已經夠糟，對此渾然不覺更是糟上加糟
- 我們沒找到多少 bug，其實也沒怎麼找：被列為「最佳」（每行 bug 數最低）的三個元件，其實有超過七成程式碼根本還沒成功簽入建置。客戶用錯了地圖，等於盲飛
- 我們竄改紀錄讓 bug 看起來沒那麼嚴重：嚴重度數字被立可白塗掉改寫——高的改低、低的改高，美其名為「開發經理修正測試人員的誤判」。這組織永遠會高估自己邁向品質的進度
- 不在我的元件裡，我就不記錄：測試人員繞過選單錯誤，卻說「這不是我的元件，不必記錄」。這可能是整個組織文化的缺陷，比單一經理竄改紀錄更難根除
- 我測錯了應用程式卻不自知：一名測試人員花好幾小時測試「捲軸」，但捲軸其實屬於瀏覽器，不屬於受測系統。問題不在這一個人，而在背後缺乏監督、訓練與篩選
- 最糟的元件因為太花時間所以不測：「快遲交的程式碼來不及做單元測試」——但最該徹底測的，恰恰是最晚交的程式碼，因為它晚交正是因為開發者做不出來。管理把事情弄反了
- 我們找到好多 bug，所以不可能還有了：一場 BugFest 找出 282 個 bug，下次又找出 343 個新 bug，客戶卻興奮宣布「即將出貨」。他們對「已找到的 bug」與「剩餘的 bug」之間的關係毫無概念
- 我們的測試證明了程式正確：總經理面不改色地說「因為我們的測試證明了它是對的」。但沒有任何測試量能「證明」程式「正確」，「正確」甚至不是個可定義的概念
- 我們跑了太多測試案例，多到看不完：「我們跑了六十萬個測試案例，沒有任何一個讓系統當機」——這句話藏著第二個謬誤：沒當機不代表沒問題
- 三個使用者沒問題，一百個顯然也沒問題：1 人 10 毫秒、2 人 20 毫秒、3 人 30 毫秒，於是推論 100 人就是 1 秒。這是線性謬誤（Linearity Fallacy），屬於**組合謬誤（Composition Fallacy）**的一種——以為兩個小系統合起來剛好是兩倍大。十公斤鈾-235 加十公斤是二十公斤，但累加幾次後不是五十公斤，而是核爆
- 我們不想讓測試人員知道我們忽略了他們的資訊：測試人員在會議上提出十五個失敗測試（產品根本建置不起來），會後開發主管的 email 卻只報告「兩個重大問題」，且 cc 名單刻意排除所有測試人員。這不只是竄改，還是扭曲他人的資訊
- 我不回報 bug，這樣開發者就不會生我的氣：測試人員口頭而非正式記錄 bug，因為「記錄她會對我吼，因為這讓她難看」。「靠吼叫管理」不是成功的領導策略
- 這個不必測，因為這個開發者很厲害：測試計畫漏掉某元件，理由是「開發經理保證這位開發者很細心」。就算真有這麼厲害的開發者，為何不讓她去把其他人也帶到同樣水準？
後設資訊只是「線索」，需要追查#
這些故事只是供你詮釋的線索，不是定論。也許那隻喜樂蒂頻頻在地毯排便，是身體出了需要看獸醫的毛病，而非飼主以為的行為問題。
關鍵教訓在於：
- 用提供的線索驗證你的直覺，或找到另一種詮釋
- 就算你的直覺完全正確，也很難輕易說服別人——你得蒐集其他證據或盟友
- 當一個問題在「解法明明很明顯」的情況下仍持續存在，你得先弄清楚別人是如何把這些明顯證據合理化掉的，否則無法說服他們解決
小結#
如果你學會運用後設資訊——也就是關於資訊品質的資訊——就能大幅提升測試的效能並降低成本。
常見錯誤#
以下是忽視後設資訊時最常見的失誤。
- 以為所有相關資訊都在測試報告裡：就算所有測試都被回報，你需要的資訊至少有一半不在報告中
- 以為坐在辦公室就能掌握測試現況：報告應以你親自的直接觀察來驗證
- 以為測試能「證明」任何事正確：測試只能顯示某物在特定條件下失敗或未失敗。如巴赫所言：「我不做證明的生意，我做證據與推論的生意。」
- 以為文件光是存在就有價值：不用就一文不值；若它誤導而你又用了它，那比一文不值更糟
- 放任待評估／待修／待指派的 bug 清單膨脹到超出人能理解的程度：必要時可宣布「bug 大赦」——清空資料庫，請所有人重新提交仍在意的 bug。作者用這招解決了那個 14000 筆的資料庫
- 責怪人，逼得他們有動機去隱藏 bug：bug 不離開辦公室就不算錯誤——每一次有人竄改紀錄，你就失去一份能幫你管理專案的資訊
- 獎勵「做做樣子」的人：有效測試需要同時專注（concentration）與聚焦（focus），有專注卻無聚焦，看起來漂亮卻成就甚少
- 不記錄每一個被發現的失敗：捕捉到的失敗太有價值，不記錄就會被忽略，等於丟掉金錢與時間
- 過度記錄每一個失敗：記錄成本很高。巴赫建議「順帶一提（MIP, Mention In Passing）」策略——某些 bug 不寫昂貴的正式報告，改以 email 或口頭告知。但作者偏好至少在資料庫給它一個編號，以免有人靠「記不記錄」的把戲扭曲統計
- 讓情緒決定測什麼、報什麼：稍不小心就會助長霸凌與共依存（co-dependency）
- 用虛假的模型評估進度：你找到的 bug 越多，代表後面還會找到更多，而非更少——沒有完美的開發者
- 假定官方流程描述總是被可靠且正確地遵循：流程描述只是「描述」，且是理想流程的描述，並非實際發生的事
- 相信客觀性：所有資訊都經過詮釋，因此都帶有某種程度的主觀，要警覺影響資訊品質的各種力量
- 未仔細審查用範本產出的文件：範本確保格式統一、外觀漂亮，卻常掩蓋不可靠的資訊