「優柔寡斷，成功的首要元素。」——安布羅斯・比爾斯（Ambrose Bierce）的《魔鬼辭典》以反諷筆法寫下此條。
在詮釋測試資料時，「猶豫」確實是件好事——但有個限度，這個限度由**三的法則（The Rule of Three）**界定：
三的法則：如果你想不出至少三種對測試結果的可能詮釋，就代表你想得還不夠。
同樣的報告，多種意義#
測試人員洛基（Rocky）丟出壞消息：「測試顯示專案必須延期，有四個 bug。」濾掉他的詮釋後，剩下的純資料只有「有四個 bug」。專案經理金姐（Ginger）該怎麼辦？
- 案例一（四個 bug，五種意義）：追問後發現，受測的 X-TERMINATOR 本身就是 bug 追蹤系統，而其中一個 bug 是「洛基無法登入回報 bug」，另三個是登入畫面的拼字錯誤。金姐可導出多種意義：洛基若登入不了，「測了整個系統」根本不是有用的描述；若連登入都做不好，系統其餘部分可能更糟；為何測試人員要用一個未經測試的 bug 回報系統？
- 案例二（四個 bug，七種意義）：在另一個平行宇宙裡，洛基交出四筆「帳號 1 ～ 4 讀寫權限錯誤」的報告。金姐可形成的意義包括：洛基大多在權限區測試、X-TERMINATOR 大多數 bug 在權限區、也許底層只有「一個」共同錯誤、洛基可能不聰明（沒想到關聯）也可能很聰明（沒武斷地丟掉看似冗餘的資料）
- 案例三（四個 bug，自己造意義）：巴赫（James Bach）的版本最妙——四個 bug 竟是「這產品盜用了我寫的開源碼、文件抄襲、splash 畫面寫著別的名字、我的版權聲明被移除」，他威脅要請律師寄正式報告
單純的 bug 計數作為測試報告，除非當成進一步調查的起點，否則比沒用還糟。別以為更花俏的報告就更好——若一套報告系統看似「不需要閱讀、分析與詮釋就能賦予意義」，那只代表你正被這套系統操弄。無論結果如何呈現，都要警覺自己可能被它「看似客觀」的外表誤導。
詮釋前，先知道你期待什麼#
電腦科學家培利斯（Alan Perlis）曾對作者說：「沒有錯的程式，只有不同的程式。」作者後來才懂這句話：他想要一個「隨機讓作業系統當機」的模擬器來訓練操作員，怎麼也寫不出來，最後團隊發現——一群物理學家那個失控的 FORTRAN 程式正好隨機當機。
接下來四年物理學家始終沒把程式弄「對」，但對作者的訓練用途而言，它從一開始就完美運作、沒有任何 bug、不需更動。對物理學家是失敗的程式，對作者卻是完美的程式。
教訓是：如果你不知道程式「應該」做什麼，就永遠無法確定它「錯了」。這也是作者強力提倡「測試先行（test-first）」的原因——開發者在寫程式前先寫下含預期結果的測試。
但測試先行有風險：人在心理上難以測試自己的程式。若不搭配結對編程（pair programming）或其他「多一雙眼睛、多一個腦袋」的流程，光靠測試先行仍有風險。在更高整合層級、更高安全要求下，最好再加上由專業人員執行的獨立測試。
若不知道期待什麼怎麼辦？#
詮釋結果時若不知產品該做什麼，可先問：
- 這東西有沒有做「重要的人」想要它做的事？
- 有沒有「不做」重要的人不想要它做的事？
- 這些測試結果對此說明了什麼？
若連「重要的人想要什麼」都不清楚，就回報你以為他們想要的、你發現的，以及兩者落差。但小心別用自己的想法過度影響他們——否則他們表面同意，等你測完才說「不，這不是我要的」。
例如對話框比規格偏左一個像素，重要嗎？視情況而定。你可以乾脆「不賦予意義」，直接回報：「對話框比規格偏左一個像素，這可接受嗎？」
善用你已有的資訊#
通常你無法只靠報告內的資訊來賦予意義。在盲目要求更多之前，先從手上已有的資訊開始。
經理道格（Doug）埋首於成堆文件想找專案延期的證據，員工海倫（Helen）問起上週營運部該跑的驗收測試，道格嘆道「沒結果可用，因為他們裝不起來軟體」——但「營運部裝不起來軟體」本身就是一個關鍵的測試結果。
也要善用間接資訊：妥善記錄的 bug 報告含有遠超過「位置與重現步驟」的資訊——每次測試與回報的日期時間、執行者、軟體與版本、作業系統、瀏覽器、組態、工具、原始語言、對先前報告的引用，以及各種自由格式註解。許多最棘手的 bug，只能透過這些看似瑣碎的資料才能理解。
把這些資料的蒐集與輸入設計得越簡單、越自動越好，否則人們不會忍受它。
善用你「沒有」的資訊#
賈羅德（Jarrod）測試撥接功能，回報「連線失敗」。羅塞拉（Rosella）用資料提問挖掘：「你看到或聽到什麼讓你認為連線失敗了？」→「聲音都停了」→ 反覆追問後得知他看到螢幕顯示 NO CARRIER。此處「缺失的資訊」是賈羅德對撥接連線經驗不足——於是羅塞拉安排他與有經驗的人共事。
同一個字可能有多種意義#
- fault（斷層／過失／錯誤）：在地震帶外多指「責備」，但在測試術語中指軟體的底層「裂縫」，而非責怪人。測試人員說有 fault 時並非歸咎於誰
- 「相同」未必「等同」：1956 年 FORTRAN 剛發明時，作者花大把時間查一個間歇性失敗，竟發現
1.2不等於1.2——因為「原始碼常數轉浮點」與「輸入常數轉浮點」由不同人寫的轉換程式。從此他對「看似相同卻來自不同來源」的東西保持警惕，建議把「相同」換成「看起來相同」
有時不精確反而更好#
弔詭的是，傳達意義時，使用模糊語言有時比精確更有效——因為人們常跳過「賦予意義」、直接進入「賦予重要性」，對一個下意識假設的意義產生即時情緒反應，反而聽不進你本意。
例如對無法擺脫「error／fault」責備意涵的人，改用較不精確的「bug」或「issue」。作者引用一段客服對話為範本：客戶因宗教信仰排斥「icon（圖示／聖像）」一詞，客服試圖「糾正」他的情緒（解釋這是業界術語）只讓他更激動，最後客服改說「點那個小小的檔案櫃圖片，『小圖片』可以嗎？」客戶才順利點下滑鼠。
「糾正」別人的情緒，幾乎註定他們收不到你的意思。在意義可能分歧的情境溝通時，多想想接收者，盡量用對方的術語。
小結#
資料不會自己說話，也並非毫無歧義。賦予資料意義是人的責任，而每個人賦予的方式都不同。最好謹記：同樣的資料有許多可能的詮釋。
常見錯誤#
以下是賦予意義階段最常見的失誤。
- 對資料意義妄下結論：行動前先想出至少三種可能意義（即遵循三的法則）
- 跑測試卻不事先記錄預期結果：心理上太容易在「看起來對」時就宣告測試成功、產品無 bug。事先記錄預期，但也要準備迎接意外
- 過度事先記錄預期結果：別把上一點做過頭——像「電腦不該爆炸、作業系統不該當機、使用者不該受傷」這類預期可以一次列給所有測試，不必每次重寫
- 試圖獨自賦予意義：眾人之腦造就多元意義，讓整個團隊參與以降低遺漏重要結論的機會
- 以為意義就完全決定重要性：對攝取套用三的法則還不夠——同樣的意義對不同的人有不同的重要性