判斷重要性

「藝術的目的不在於再現事物的外在樣貌，而在於其內在的重要性。」——亞里斯多德（Aristotle）

什麼是重要性？#

重要性（significance）是「有權決定如何處理某 bug 的人」賦予該 bug 的重要程度。定義看似直白，但本章用一個情境劇展現它的複雜。

專案經理綺莉（Cheri）正要赴舊金山的展會發表遊戲 3.0 版，測試經理馬夫（Marv）卻宣布找到嚴重 bug：角色會隨機消失再出現。同一個 bug，每個人賦予的重要性卻天差地遠：

馬夫（測試經理）：認為極其重要，主張延後發表
魯隆（行銷經理）：認為無關緊要——這次展會成功發表能多搶 10% 市佔，價值至少一億美元
綺莉（專案經理）：她的重要性是「個人的」——bug 在展會出包她會丟工作，但乾脆不展出她也會丟工作
菲爾（業務）：認為這不是 bug 而是「別的遊戲沒有的特色」，會大賣
奈塔（3.0 版設計者）：說十五分鐘就能修好，因為她這週實在無法出差

不同的人對同一資訊賦予不同的重要性#

bug 的重要性，取決於「誰有權決定如何處理它」。除非綺莉的老闆推翻她，否則由綺莉決定。其他人眼中的重要性，只在綺莉認同的程度內才算數。

理想上，綺莉應從每個團隊成員——以及法務——萃取出各自觀點的重要性，問法統一為「若我們放著不管／若我們修好它，這對 ○○ 會有什麼影響？」：

馬夫：對「測試」的影響
魯隆：對「未來銷售」的影響
奈塔：對「開發」的影響
菲爾：對「季營收」的影響
律師：對「法律責任」的影響
客服主管史旺森：對「支援成本」的影響

公開的重要性可能不同於私下的#

若人人都理性、公正、坦白，評估重要性就很簡單。但人們可能有隱藏的個人盤算，扭曲他們的答案。

馬夫想趁展會後去舊金山參加一場稀有棒球卡拍賣，延期他就得自費
魯隆認為自己是下一任專案經理人選，綺莉若失敗他就上位
奈塔有錢的叔叔正在改遺囑，她出差期間表親會討好叔叔，她恐失去鉅額遺產
史旺森覺得客服不受尊重，想藉「輕鬆搞定這問題」抬高自己在高層眼中的份量

因此綺莉若要做出合理估計，就得設法濾掉所有人的個人盤算——包括她自己的。

重要性取決於脈絡#

重要性不只是「bug 與人」的屬性，還取決於脈絡：

對「已記錄數十個錯誤的程式」中的第 n 個錯誤，多數人賦予的重要性，與對某元件「有史以來第一個錯誤」不同——早期 bug 發現是元件未來行為的最佳預測指標，快速找到大量 bug 意味著長期還會找到更多
這也是要記錄所有 bug 的原因：漏記會讓我們誤判早期 bug 不多，從而掩蓋「這元件日後會出問題」的事實

關於機率與期望值：

一個錯誤的期望值（expected value）= 遭遇機率 × 遭遇成本
每天用、每次都失敗但每次只損失一分錢 → 一年約 3.65 美元
一年只遇一次但會摧毀所有資料、復原要兩萬美元 → 一年兩萬美元

還有一層複雜：「誰來承擔失敗的成本？我們在乎嗎？」作者的姪女用某文書軟體排版出書，該軟體每約十頁就漏一個字，印了上千本才發現。作者向身為其客戶的開發團隊回報，對方說「我們知道這 bug，但決定不修——它只在文件超過約兩百頁時發生，多數使用者夠聰明不會把雞蛋放同一籃；硬修可能製造影響數千人的新 bug」。對開發者而言姪女的書稿不重要，對她卻是天大的事。

不能總是用金錢來判斷重要性#

BQ 公司的律師回電提醒：去年有兩名男孩模仿競品遊戲的橋段而喪命，「萬一有孩子模仿角色消失術而死，我們會被告到賠數百萬」。奈塔喊道：「這是人命，你不能標價！」

但人們其實一直在為人命標價。1930 年代建造金門大橋時，橋梁建造者預期「每百萬美元工程成本死一人」，若不為人命標價，這座橋根本不會動工。同時，他們也藉「標價」決定加裝安全網，救了 19 條人命。

作者更以親身經歷說明：他曾參與 NASA 水星計畫（Project Mercury），負責為「人命」賦予 bug 重要性等級：

Level 0：此軟體錯誤可能導致有人喪命
Level 1：此錯誤可能導致任務中止
Level 2：此錯誤可能延誤發射或太空人接返
Level 3：此錯誤會帶來額外成本

Level 0 永遠凌駕一切。IBM 總裁小華生（T.J. Watson, Jr.）特別指派作者把關，任何人想推翻 level-0 bug，就得親自去紐約向華生陳情。十四個人想推翻，但一聽說要找華生就全都退縮了——華生對重要性握有最終定奪權，這顯然把他們的論點放進了不同的脈絡。

別把刻度切得太細#

人命的價值永遠是主觀的，事實上所有重要性度量都是。許多公司用一堆數字花招讓判斷「看起來客觀」，別被騙、也別騙自己。

作者曾有客戶用 0 到 100 分的量表判斷 bug 重要性，會議上為了加減一分爭執不休。作者統計後指出：幾乎所有 bug 在「決定先修哪個」所花的時間內就能修好。之後類別縮減為四級。

實務上的四級分類（從測試角度）：

Level 0：此問題正阻擋其他測試
Level 1：不解決產品就無法使用
Level 2：不解決會顯著降低產品價值
Level 3：只有出貨時存在大量類似問題才重要

優先處理重要的問題#

測試人員對重要性的看法不該決定「如何處理」一個失敗，但應該影響各測試的執行順序。

如果「測試先行」是好主意，那「重要性先行」更好。你可能執行無限多測試，但即使只執行了極大量測試，也可能把有價值的資訊淹沒在無用的垃圾中。測試數量應盡可能小，但不能更小。先估計每個測試的重要性、先做最重要的——這樣無論何時決定停手，都已在有限時間內做到最好。

傾聽你的情緒反應#

重要性，就是你賦予測試結果的意義所帶來的「情緒衝擊」。

電腦程式有時會「因錯誤的理由而正確」。作者以閏年為例：論壇成員大衛（David）測試某知名試算表，發現它把 1900 年 2 月 28 日的隔天標為「2 月 29 日」（但 1900 不是閏年），而 2100 年卻判斷正確。

對一般使用者，這個閏年 bug 或許無關緊要（沒人活在 1900 或 2100）
但若你打算把這試算表嵌入賣給「承作百年貸款」的金融機構的軟體，這 bug 可能讓你損失大量生意
真正令作者擔憂（一種重要的情緒）的是：他對黑箱內部的心智模型「崩塌了」——他完全猜不透開發者在做什麼，而這一點本身就夠重要了

進一步追查發現，這試算表其實有「兩個互相抵消的 bug」：1900 年 1、2 月完全亂掉，但從 3/1/1900 起星期就對上了。

小結#

我們的情緒承載著「事情有多重要」的資訊。如果我們留意情緒、傾聽，並在處理不重要的事之前先處理重要的事，就是用手上的資料做到了最好。

常見錯誤#

以下是判斷重要性時最常見的失誤。

把修復難度與重要性混為一談：修 bug 只是其潛在成本之一。系統當機可能無關緊要，而一個打字錯誤卻可能是災難——作者知道一個案例：發票上誤印的電話號碼讓某救護服務被錯誤來電灌爆，至少害死一人
誤判「回應速度」的重要性：答案來得比預期快，我們會「懷疑」它不對；耗時符合預期，我們就「相信」它是仔細算出來的。例如火星軌道器若五分鐘內回傳答案，必定有問題（光傳輸延遲就不止於此）
沒意識到重要性是政治性的：例如「坐牢」無法純用金錢衡量
相信有「理性」或客觀的方式評估重要性：你可以用數字與演算法輔助，但最後一步永遠是衡量你對那些數字的情緒反應
新資訊出現時未重新評估重要性：重要性是整個系統（含建造該系統的流程）的屬性，要定期檢視並準備改變
任由「催眠語言（lullaby language）」影響你的評估：某些字詞會為資訊染上意義。當有人說「回應應該要很快」，「應該」「很」「快」各自給了多少意義？
忽視你的行動對團隊本身的重要性：測試人員常對測試有情感投入，得知自己找到的 bug 下版不會修時會洩氣，心想「反正不修，我何必回報」。試著區分「忽視」與「有意識地選擇不修」