取得資訊的方式#
想像你是一套價值數百萬美元的物流系統的主管。公司總裁貝尼托（Benito）作風強硬，會在會議上當場開除答不出他想要答案的人，而他急著上線。你問專案經理進度如何，她卻回答：「我不知道。」
面對「我不知道」，你想要更多資訊，方法有幾種：
- 嚴刑逼供：逼她說出「很好！」——但這得不到可靠資訊
- 拔擢馬屁精：開除她，提拔一個說「我知道」的人——同樣不可靠
- 蒐集資訊：觀察程式在真實使用情境下實際做了什麼
「蒐集程式實際運作時的資訊」正是某些人所說的「測試」。三種方法中，只有它有機會得到可靠資訊。
資訊不必然能降低風險#
軟體業的管理者常需做出有風險的決策，例如：現在出貨還是延後？要不要取消專案？要不要加資源？要不要縮減範圍？
這些決策可以完全不靠資訊就做出——而且經常如此。更常見的是，決策者拿到一點資訊後，卻刻意忽略其他可取得的資訊。
既然測試是一種蒐集資訊的流程，就永遠存在一個問題：付錢做更多測試值得嗎？
關鍵在於：組織裡有人握有決策權。若那個人無論拿到什麼額外資訊都會做相同決定，那測試蒐集資訊就沒有意義。如果貝尼托已經決定系統照原樣上線，何必再給他資訊？何必測試？
測試本身也可能增加風險#
測試無法在零時間內完成，也無法免費完成。
測試有時反而會加大風險：
- 時間與金錢成本：若貝尼托為了等更多測試而延後產品，可能太晚進入市場，或在測試上花到破產
- 修復衝突：開發者一旦得知某處運作不佳，就會想花時間去修，這可能破壞原本「夠好可用」的部分
- 法律風險：若有人因軟體錯誤控告你，他們可以調閱你的開發紀錄。要是紀錄顯示測試人員早已發現某 bug、你卻沒修，你的處境會比「從未發現」更糟
「無知是福」的原則也適用於個別管理者：產品在現場出問題時，誠實說「我不知道」的後果，往往比「明知卻不作為」來得輕。請仔細想清楚——你最重要的目標到底是做出成功產品、避免訴訟，還是只想升官？
你可能沒在用付錢買來的資訊#
「我們該多做測試嗎？」永遠沒有簡單答案，因為資訊能引導風險降低，卻不必然如此。一款測試過卻仍不好用的軟體，未必是測得不好，也可能是測了卻沒人據此行動——測試不是修復。
由此延伸出一個問題：你真的拿到了花錢請測試人員產出的資訊嗎？
小心落入「以資料數量等同資訊品質」的陷阱（bug 數、報告頁數、執行的測試案例數）。有時候，資訊的缺席反而是最重要的資訊。
當測試人員沒挖出大量 bug 時，背後可能藏著關鍵訊息：
- 他們花了六週加班卻裝不起來軟體——若連測試人員都裝不起來，使用者怎麼可能裝得起來？
- 他們看不懂軟體——這同時透露了組織的資訊流問題：說不定有開發者也同樣困惑，於是寫出了不能運作的程式
- 他們不會測、測不好，或根本不在乎
作者指出，他聽到的測試抱怨有一半來自「未追究測試結果中所有資訊」的管理者。如果你不打算使用產出的資訊，就別付錢做測試。
我們的決策是情緒性的，而非理性的#
既然測試能降低決策風險，照理說人人都該喜愛它。但人們做決策有許多與「理性運用資訊」無關的心理因素——「我心意已決，別拿事實來混淆我」這句話我們都聽過，甚至說過。
人們對「不去發現自己犯了錯」有著情感上的投資。有些管理者不想知道專案正滑向失敗，有些開發者不想讓人知道自己的程式有 bug。
正因如此，任何想影響這些情緒因素的介入都容易適得其反：
- 為「bug 數低」的開發者設獎金，本意是鼓勵寫出更好的程式碼。但這反而讓 bug 更受注目，餵養了「不想讓人知道我有 bug」的心理——有人因此把產品弄得難以測試，心想「測不出來就不影響我的獎金」
- 公開拔擢每位準時出貨的經理，結果某位經理面對大量 bug 報告時，心想「我要那個升遷，得準時出貨，但這些 bug 報告礙事」，於是把測試人員調去別的專案，讓開發者「趕上進度」
給管理者的提醒：在這種情況下，開發者永遠不會「趕上進度」。
糟糕的測試可能比不測更糟#
「糟糕的測試」（構思不良或執行不良）會帶來雙向誤導：
- 讓你以為產品比實際更好，於是過早出貨
- 讓你以為產品比實際更糟，於是延後出貨、錯失效益
如果你懷疑自己會把測試做得很糟，那不如乾脆不要測。
你的產品可能還沒準備好接受測試#
判斷產品何時可以測並不容易，但你可以用幾個較易回答的問題反推：
- 有沒有至少一個測試能幫你回答的問題？沒有問題就沒有理由測試
- 你想知道那個問題的答案嗎？不想知道就別問
- 你只是「閒著好奇」嗎？若不打算評估或據此行動，就別測——測試太貴，不該用來滿足閒散的好奇心（但主動的好奇心是有效測試的重要特質）
- 你能事先和測試人員就「何謂通過的測試」達成共識嗎？
- 你是否認同「任何帶來新資訊的測試，至少都算部分成功」？
- 你以為測試結果會「替你做決定」嗎？商業決策不能純從技術角度做出
出貨一個沒通過部分測試的系統，可能是好的商業決策；反之，出貨一個通過所有測試的系統，也可能是壞的商業決策。測試結果只是商業決策的參考之一，不能取代決策本身。
反過來問：有沒有任何測試結果會讓你改變決定？若沒有，你為何想知道結果，甚至付錢去取得？
小結#
如果基於任何理由，你都不打算使用測試產出的資訊，那你就不必測試。而如果那些資訊不會切題或不可靠，你最好也別用——那就別一開始就花錢買它。
常見錯誤#
以下是管理者在運用測試與測試人員時最常見的失誤。
- 不尊重測試人員：若你不打算相信他們的發現，要嘛是用錯了人，要嘛你得認真協助他們建立公信力
- 過度尊重測試人員：若你讓他們替你做決定，那你該下台、把經理的薪水讓給他們賺
- 拿測試人員當代罪羔羊：假意尊重、操弄他們給出你想要的答案，事後出錯就推給他們
- 不使用測試或其他來源得來的資訊：若你打算無視資訊、照既定計畫硬幹，就別測（你不用的東西其實稱不上「資訊」）
- 做出情緒性而非理性的決策：你無法做到完全理性，但至少可以試著在決策時保持冷靜與自制
- 不評估測試資料的品質：數字只是數字，要學會問「這個數字是用什麼流程得來的？」「它代表什麼意思？」
- 準備不足就測試：「充分準備」指的是你必須有能力在問題出現時辨認出來，至少要對受測程式的目的與本質有基本理解
- 未將測試與專案其餘部分協調：若你不給開發者時間與資源去修正測試發現的問題，測試就是白費工
- 催促測試人員：測試常是細膩的工作，催促往往產生危險的誤導結果——尤其當測試人員處於恐懼、疲憊或憤世嫉俗的狀態
- 不要求管理者盡責：若你容許管理者以「不懂測試流程」為由放過 bug，那不如別測
- 僅因他人決策與你不同就認定其不理性：許多看似不理性的決策，是依據另一套價值觀而言的理性決策
- 沒意識到測試資訊有不只一種用途：許多情況下，產品交付後仍可繼續測試，以蒐集對客服與支援團隊有用的資訊