「事物本無好壞，全看思考使然。」——莎士比亞（William Shakespeare），《哈姆雷特》
什麼造就一個好測試？這問題可以用高度技術性的方式回答，但本章選擇退一步，從管理者的角度看：你怎麼知道測試做得好？你又能給測試結果多少信任？
你永遠無法確知#
先看比「好」更高的標準——「完美」。一組完美的測試應具備：
- 偵測出系統中每一個 bug
- 絕不把非 bug 誤判為 bug
- 讓我們完全有信心它做到了前兩點
- 又快又省地完成以上三點
問題在於：我們事先並不知道受測的是無 bug 的完美系統，還是爛系統（若知道，何必測試？）。當「完美測試」與「爛測試」都對一個無 bug 系統回報「找不到 bug」時，光憑找 bug 的能力，我們根本分不出兩者差別。
由此推出一個關鍵觀念，層層遞進：
- 對某個實作而言夠好的測試，對同一系統的另一個實作可能很爛——「好」不是測試的屬性，而是「測試與實作之間關係」的屬性
- 同一測試、同一實作，對某組織夠好、對另一組織卻很爛（例如供單一組織內部使用 vs. 賣給上千家組織）——「好」是「測試、實作與情境三者之間關係」的屬性
所以你永遠無法確知一個測試是不是好的，也無法靠孤立地看一個測試來判斷。但你有許多方法判斷一個測試很可能是壞的——後設測試在此扮演重要角色。
只能事後評估好壞#
如果你知道系統裡有多少 bug，至少能開始評估一組測試的好壞。系統使用幾年後，審慎的管理者會累積統計資料，藉由追蹤實際使用中浮現的 bug，得知：
- 你的測試「慣性」漏掉了多少 bug
- 你的測試「慣性」漏掉了哪些「種類」的 bug
但你永遠無法確知出貨時帶了多少 bug，因為 bug 可能在很多年後才浮現，或永遠不浮現。作者的《程式設計的心理學》賣出二十多萬冊、出版三十年後，才收到一封信指出一個「明顯」錯誤——這既是作者謙遜的一課，也說明「明顯」錯誤能潛伏多久。
而且，若你等五年才評估測試好壞，資訊還有什麼用？測試人員可能已換工具，原始碼或 bug 報告可能已遺失或看不懂。若只等半年到一年並保留良好紀錄，評估或許還能及時用於改善未來測試。
比起被動等待經驗，你還能：
- 對照你的失敗理論，審查覆蓋率與判準（oracle）
- 隨機或任意地變動測試，觀察問題如何浮現
- 平行比較不同測試（如 beta 測試 vs. 內部測試、審查 vs. 動態測試）
你可能想刻意植入 bug#
有時可透過「播種」來量化估計殘留問題的數量，作者把這稱為 bebugging（他相信此詞是他在《程式設計的心理學》中所創）：
- 不告訴測試人員，先植入已知 bug
- 再依他們找到的已知 bug 百分比，估計殘留的未知 bug 數量
bebugging 要合理運作，植入 bug 的分布必須貼近未知 bug 的（未知）分布——這本身就很難。即使所有已知 bug 都被找到，它能提供的可靠資訊也不多。
好壞估計永遠是統計性的#
對好壞的估計終究只是「估計」，因為我們永遠無法確知系統裡有多少 bug。系統實際 bug 越少，統計越對我們有利：若只有 10 個 bug，50% 誤差代表差 5 個；但若有 14000 個，就可能差到 7000 個。
許多管理者以「找到多少 bug」評斷測試人員，這意味著品質越差的系統反而讓測試人員看起來越好——測一個完美系統的人會因找不到 bug 而被當成無能開除。在這種衡量制度下，爛開發者成了測試人員最好的朋友。
為何這種有缺陷的制度如此流行？
- 測試人員疏於解釋他們「如何」找 bug、為何其策略值得尊重
- 當管理者與開發者預設產品「能用」時，告訴他們「它能用」彷彿沒提供資訊——「沒資訊」被當成「沒價值」。這就像人們不換煙霧警報器電池：壞掉的警報器在行為上與正常的難以區分，而最常見的「該換電池」提醒，竟是一場火災
你可以估計「不壞」的程度#
測試最深的技術層次涉及深奧的數學與邏輯，多數管理者得仰賴獨立專家的第二、第三意見。但有許多「不壞」的評估，管理者可以自己透過提問做到：
- 測試聲稱能提供我要的資訊嗎？不能就顯然不好
- 它有文件嗎？若無，你是否親自觀察過，或由你信任的人觀察、回報、執行？
- 它誠實嗎？文件被造假的方式有很多種
- 我看得懂嗎？看不懂怎麼判斷好壞？
- 它至少涵蓋了最重要的部分嗎？無法測遍每條路徑，但至少每行程式碼都該被走訪一次
- 它真的完成了嗎？任何人都能在測試計畫上打勾，你有辦法知道實際做了什麼嗎？
- 我能分辨「測試」與「展示（demonstration）」嗎？展示是設計來讓系統「看起來好」，測試是設計來讓系統「呈現真實面貌」
- 趨勢與狀態報告是否過於簡單規律？真實專案的測試形形色色，過於可預測的趨勢可能代表測試很淺，或報告漏了重要的東西
- 不同測試活動之間是否有矛盾？例如 beta 測試找到內部團隊沒找到的 bug、或效能測試找到功能性 bug，可能代表某流程運作不良
- 管理者現身了嗎？他們不該盯著別人肩膀看，但一位以「會關注」聞名的好奇管理者，光是現身往往就能改善測試
小結#
你永遠無法確知測試是否做得好，但有許多方法能得知或估計它是否做得壞。
常見錯誤#
以下是評估測試品質時最常見的失誤。
- 不去想你要的是什麼資訊：你通常無法事先確知要找什麼，但至少要思考最終的測試目標
- 以「找到多少 bug」衡量測試人員：他們會回應這種衡量，但多半不如你所願——bug 數量會增加，資訊品質卻會下降
- 以為能確知一個測試有多好：評估測試的準確性與適切性時要保持警覺與懷疑，否則會被「不偏袒完美主義」的宇宙本質狠狠教訓
- 沒把情境納入考量：幾乎沒有任何測試在所有情境下都同等重要，忽略潛在使用模式，測試就會無效
- 在不了解產品內部結構的情況下測試：了解結構能幫你辨認特例、細微功能與重要範圍，縮小「能做」與「實際會做」之間的推論落差
- 在過度了解內部結構的情況下測試：太容易為「你以為的黑箱內情」開脫；典型使用者不會這樣，所以有些測試最好模擬天真使用者的行為
- 把 bug 的統計估計說成固定、確定的數字：陳述估計時務必給範圍（如「這版大約有三十到四十個 bug」），最好給統計分布或圖表
- 沒對你的測試套用「壞」的衡量：用檢核表，問本章那類問題
- 沒確保開發本身做得好：爛程式碼需要好測試，卻通常得到爛測試，問題因而加劇
- 沒考慮大量 bug 造成的測試效率損失：「完美」的測試時段是全部投入於測試設計與執行——但設定、bug 調查與回報都會佔走時間。找到一堆 bug 或許讓測試人員好看，卻會拖慢測試、降低覆蓋率，或兩者皆是