我們為何要測試

人不是完美的思考者#

假設你寫了一套你「確信完美無缺」的投資策略軟體，打算用畢生積蓄照它的建議投資。你會在投入每一分錢之前先測試它嗎？如果是別人寫的程式呢？

作者用這個提問篩選讀者：

本書的根本前提是：人類不是完美的思考者。如果你的思考真能完美無誤，你就不需要測試。

真正的人都知道，無論多麼努力想把事情做到盡善盡美，總有犯錯的時候；也知道別人同樣會犯錯。正因為承認這份「會犯錯」的本質，我們才能透過測試，做出比不測試時更好的決策——但只是「更好」，不是「完美」。

很多時候我們其實一直在做測試，只是沒意識到。作者以自己尋找網頁編輯軟體的經歷為例，記錄了一連串「沒當成測試的測試」：

注意：上述許多「測試」作者完全沒碰鍵盤就完成了。測試遠不只是動手操作軟體而已。

最後作者選擇繼續沿用他那套老舊、無人支援卻可靠的軟體。這些行為可稱為「驗收測試（acceptance testing）」，而反過來看，它正揭示了從生產者角度出發的測試理由：你測試，是為了知道你的軟體賣不賣得出去。

即使是被組織強制使用的內部使用者，本質上也需要被「說服」。別自欺欺人——使用者總有辦法不去用他們不想用的軟體。

我們當然可以完全不測試就做決策。但對許多決策而言，多一點資訊就能提高得到滿意結果的機率。換句話說，資訊能幫助降低風險（risk）。

好的測試在於權衡兩者：

在開始測試前，先問自己：

如果你對產品的風險沒有任何疑問，那就沒有理由測試。

作者以「網頁編輯軟體」與「心律調節器（pacemaker）嵌入式軟體」對比說明：兩者的失敗後果天差地遠，自然不能套用同一套測試流程——沒有人會把隨機抓來的免費心律調節器軟體裝進活人體內。

風險評估本質上是主觀的，原因有二：

一段對話生動說明了「風險認知如何改變測試標準」：開發經理丹妮絲（Denise）問開發者勞夫（Ralph）單元測試是否充分，勞夫信誓旦旦說「非常徹底」。丹妮絲於是提議：若測試階段發現少於三個 bug 就加薪，三個以上就今年不加薪。勞夫立刻改口：「能不能把元件先還我，我還想做幾個小測試？」

當錯誤的後果被提高，勞夫對「何謂充分的單元測試」的認知瞬間改變了。

不同的人、專案與時機，對風險有不同認知，因此測試要回答的問題也不同。常見的基本問題包括：

至於測試量該做多少，取決於失敗的可能性與後果：

以下是管理者與團隊在看待測試時最常落入的陷阱。

追求完美：完美無法達成，企圖做到不可能的事會把你逼死
不做決策：管理者的職責是做決策，別問測試人員「軟體可以出貨了嗎？」——那是管理者的決定，測試人員只負責提供（部分）資訊
未掌握決策所需的全部資訊：若只聽開發者與測試人員的意見而忽略顧客的特殊需求，很難有滿意的顧客
對各種風險排錯優先順序：若只怕錯過升遷而硬要如期出貨，可能交付出讓公司損失數百萬的劣質產品
以為測試能改善產品：測試只蒐集資訊，不會修正它發現的問題。改善產品的是修 bug 的人。管理者常說「測試太花時間」，真正該說的往往是「修 bug 太花時間」——那是不同的成本類別
以為有一個「測試階段」：測試專家詹姆斯・巴赫（James Bach）指出，所謂「測試階段」其實常是「修錯階段」，因為它往往在測試尚未完成前就結束了

巴赫的比喻很傳神：開車時哪有所謂「看擋風玻璃的階段」？整個開車過程幾乎都在看擋風玻璃，那不是一個階段。說「測試太花時間」，就像說「安全駕駛太花時間」一樣。

測試的根源在於心理學——對人腦行為的研究。如果人類是完美的思考者，就不需要測試自己的工作；如果我們是不帶情緒的機器人，就會永遠理性地用測試來降低決策風險；如果我們是一模一樣的複製人，就會以相同方式評估風險。

但我們是不完美、不理性、由價值觀驅動且各不相同的人類。正因如此，我們才需要測試，也需要測試我們的測試。