測試與除錯的差別

「精準的定義不是預防爭論，就是終結爭論。」——神學家艾蒙斯（Nathanael Emmons）

測試之所以常背負惡名，往往源於「它到底是什麼、該做什麼」的混淆。弔詭的是，管理者若有大量開發經驗，這份釐清反而可能更困難——因為他過去一個人包辦所有角色時，從不需要區分自己當下在做哪件事。

一個人時，七種活動渾然一體#

本書以專案經理珍（Jane）的職涯為例。早年她在小公司身兼數職，一天之內流暢地切換於七種不同活動，而且毫無違和：

探索性測試（testing for discovery）：對受測軟體執行有潛力發現新資訊的動作。例如珍逐一跑情境，確認昨天的改動有按預期運作、且沒影響其他功能
釘定（pinpointing）：隔離 bug 發生的條件。例如珍確認某 bug 只在「清除選填欄位」時出現
定位（locating）：在程式碼中找到 bug 的位置以便修復。例如珍設中斷點、逐步追蹤更新資料庫的程式碼
判定重要性（determining significance）：權衡「修」與「不修」的風險。例如珍評估這個罕見 bug 值不值得冒著改動五十行程式碼的風險去修
修復（repairing）：修改程式碼以移除問題
疑難排解（troubleshooting）：排除或繞過障礙，讓軟體做它該做的事。例如珍在電話中引導客戶 Sherman 改用另一套還原流程
以測試來學習（testing to learn）：不是找 bug，而是摸索某套工具如何運作，類似 hacking、逆向工程或「玩」

只要珍持續為客戶服務，她當下在做七者中的哪一件其實無關緊要。問題出在組織變大之後。

當珍轉到大公司、團隊分工後，同樣這些活動的混淆就釀成衝突。書中以測試人員史丹（Stan）的一天為例：

問題的根源在於：組織裡沒有人對「測試人員該負責釘定到什麼程度」達成共識，於是衝突無可避免。

身為綜觀全局的專案經理，珍能終結這種混淆——關鍵是不要把這些活動全部混為一團、貼上「測試」這個大標籤。

混為一團唯一的效果，就是讓測試流程看起來「永遠做不完」。實際偵測失敗（真正的測試）只佔了「測試」這個籠統標籤下的一小部分時間，而這種模糊讓準確估算與排程變得不可能。

由於珍的職責橫跨測試、開發與支援三個團隊，她必須釐清哪些人對哪些任務負主要責任。

一個有助於釐清「誰花多久做什麼」的捷思法（heuristic）很簡單：

專案上的任何人，都不該草率地浪費專案上任何人的時間。

珍據此教導測試人員：調查一個 bug 不超過十分鐘就要通知程式設計師。對史丹來說很隱晦的問題，對寫那段程式的人可能一目了然。但這是捷思法，不是死規則：

許多需要不同技能的任務常被混在「測試」這個統稱底下。這種混為一團會扭曲規劃、估算與工作分派，對整個專案造成傷害。

以下是混淆測試與除錯時最常見的失誤。