不自覺的騙局

「樂觀者看見玫瑰而非其刺；悲觀者盯著刺，卻對玫瑰渾然不覺。」——紀伯倫（Kahlil Gibran）

外頭有許多騙子伺機利用你對測試難題的絕望，這已經夠糟，但最常見的騙局其實是無心的、不自覺的、自己騙自己的騙局。它們通常源於樂觀——當我們下意識地忽略那些棘手的資訊，因為直視它們的痛苦會逼我們承認情況有多糟。

延遲記錄文件#

最常見的自欺騙局，發生在測試人員等到週末才記錄當週測試細節（bug 與測試資料）時。詮釋或許可以等幾天醞釀，但沒人能準確記得整整一週敲鍵盤的詳細資料。

這正是作者半世紀前就建議使用追蹤日誌與工具、如今技術更好仍持續建議的原因。

語言富有表達力，意味著它可能代價高昂——同一句話對不同人有不同意義，而對測試報告的不同詮釋可能損失慘重。

作者曾評估某功能 bug 多到該移除重建。專案經理問「到底有多糟？」作者盡可能強烈地說：「你的客戶照原樣接受它的機會，不超過百分之一。」一個月後他發現經理還是出貨了，客戶大怒。「你為何出貨？」「你說過客戶有機會接受。」「我說機會不超過百分之一。」「對，所以我賭了那個機會。」

當你的飯碗岌岌可危、又有機會去誤解一句歧義的話時，猜猜你會往哪個方向解讀？

測試報告常因「人情」理由被動手腳。巴赫（James Bach）講過測試人員「不回報 bug 來幫開發者」的故事。

若測試人員覺得不必邊找邊報 bug，這本身就是關於專案的資訊：他們是否覺得需要保護開發者免受愛究責的管理層攻擊？若是，這組織必定充滿誤導管理層的騙局。

巴赫分享他當時身為該專案管理者的學習：他同意「暫緩」正式回報（而非完全不報），只是讓流程少點官僚，藉此不動用「管理鐵鎚」就能更早取得程式碼、並在團隊中建立信任。

有趣的後記：約五年後巴赫再遇到那位「神經緊繃」的開發者，對方說：「對啊，我那時真是個渾蛋，當初該無條件讓你測產品的。」人會成長，而營造成長的環境永遠是好的管理。只要小心你真正偏離成功流程的所有理由，以及你可能無意間發出的訊息。

並非所有造假報告都是為了讓開發者好看。若測試人員與開發者關係緊張，要讓特定開發者「看起來做得很差」很容易——通常是無意識地扭曲跑哪些測試與 bug 重要性評估，但也可能是有意惡為。若是後者，這是組織生病的徵兆。

另一種常見的自欺騙局，是用早期結果預測測試要花多久：「第一週修了 20 個 bug，已知有 200 個，所以總共要十週。」錯。你最先修的 20 個，幾乎依定義就是最容易修的，所以這「方法」嚴重低估了修其餘 180 個所需的時間。

同樣的錯誤發生在 beta 測試：早期使用者較不會深入操作，甚至會被 bug 擋住而試不了某些功能，因此 beta 結果傾向嚴重低估「冷門功能」中的 bug。

許多不自覺的騙局都依賴一個謬誤信念：跑了大量測試、或抓到大量 bug，就必然代表測試做得徹底。落入**「數量即品質」騙局**，你就把自己暴露於各種誤導資訊之下。

常見變種：

厚度因素（The Thud Factor）：某開發副總想要「測試文件有厚度」，好把又厚又重的測試計畫「砸」在客戶桌上展現對品質的重視——當你想知道的東西（品質）太難量測，就量一個替代品（文件厚度）
打地鼠（Hack-’n’-crack／Whack-a-bug）：bug 不是隨機發生的。若把每個 bug 當孤立個案修，會誤估真正的進展；常常釘定一個根本原因就能一次解釋並根除好幾個失敗
回歸測試 ≠ 新測試：若管理層按「跑了多少測試」獎勵，自動回歸測試可能每跑一次就被算一次。同一測試跑越多次，反而對產品與流程是越壞的徵兆——除非你修同一問題修了好幾次，否則何必重跑？
計數 ≠ 思考：計數測試會產生陰險效果——測試人員避免寫長或複雜的測試、不再互相幫忙、把測試稍作變化複製後當成不同測試。用測試計數取代觀察、對話與思考太誘人了，因為它讓你「不必聽就能假設一切」，從而製造了一池「以遺漏行騙」的謊言
BugFest：大量猴子敲大量鍵盤，不構成測試效能的有效衡量。何況找到大量 bug，到底代表測試有效，還是產品很爛？

「什麼都沒變」騙局（The Nothing’s-Changed Scam）：「我們測過了，而且什麼都沒變」其實是「……什麼都沒變（就我想得到的而言）」——而正是你想不到的那些改動，造成了大多數新引入的 bug
「都一樣」騙局（The It’s-the-Same-Thing Scam）：「我測過 X，Y 跟 X 一樣，所以不必測 Y」。作者記得一個昂貴錯誤：測試人員聲稱「從 CD 載入系統」等同「從磁碟載入」——本該如此，卻並非如此，結果所有出貨的 CD 都因無法正確載入而被召回。這正是我們測試的原因：看看「本該為真」的事是否真的為真。
部分測試當完整測試騙局（The Partial-Test-As-a-Complete-Test Scam）：測試人員把部分測試詮釋為完整測試——「我測了表格裡所有的值」（其實只測了第一個、第二個、中間一個、最後一個值，這算一樣嗎？）

卡洛斯（Carlos）與保羅（Paul）看到一份「教科書級」整齊漂亮的測試報告，去問製作者泰芮（Teri）資料從哪來。泰芮坦言：「管理層堅持要報告，但我們根本沒蒐集資料，我只好盡力『估計』如果有記錄的話數字會是多少。」

卡洛斯與保羅夠精明，沒被太乾淨、太完美的資料騙倒——真實資料從不會那麼整齊。但他們的管理層卻雙重中招：不僅把泰芮的報告當範本通令其他測試經理仿效（整齊騙局），還把她的試算表發給所有人當範本（試算表騙局——「來自試算表，就一定對」）。試算表和任何程式一樣，遵循「垃圾進、垃圾出」的定律。

當我們太希望一切順利時，就太容易把自己的幻想注入資料之中。

以下是落入不自覺騙局時最常見的失誤。