怎麼認得「這是 bug」：一致性判準

<h1 怎麼認得「這是 bug」：一致性判準</h1 <p 測試時最讓人挫折的時刻，不是找不到 bug，而是找到一個行為，卻說不清楚「這為什麼有問題」。你感覺哪裡不對，但開發說「就是這樣設計的」，你沒有辦法反駁，只能尷尬地說「我覺得怪怪的」，然後這條記錄就消失了。</p <p 問題不是你的感覺錯了。問題是你還沒把感覺背後的<strong 參照點</strong 說清楚。</p <h2 bug 是「不一致」</h2 <p 你說某個行為是 bug，背後一定有一個隱性的「它本來該怎樣」。那個「本來該怎樣」就是你的參照點。把參照點說明白，主觀的「怪怪的」就會變成可討論的客觀判準。</p <p 舉個例子。你在探索一個編輯個人資料的頁面，送出之後頁面沒有任何反應——沒有成功提示、沒有錯誤訊息，只是靜止在那裡。你覺得怪。但「怪」能讓你怎樣？</p <p 換個說法：「這個操作沒有給使用者任何回饋，但同樣是送出動作的表單（登入頁、設定頁）都會顯示成功或失敗的提示。行為不一致。」這句話，你可以寫進報告，開發也能理解你的判斷依據。</p <p 判準就是：<strong 找到你把這個行為跟什麼東西比較，然後說出那個比較。</strong </p <h2 該與什麼一致</h2 <p 探索時可以掛著下面這組參照，逐一問「這個行為跟哪個參照衝突了？」：</p <ul <li <p <strong 與歷史行為一致</strong ：上一個版本不是這樣的。例如：「之前長按列表項目會跳出編輯選單，這個版本沒有反應——功能被移掉了還是壞掉了？」</p </li <li <p <strong 與可比產品一致</strong ：同類 App 的同功能不是這樣做的。例如：「所有主流輸入法在切換語言時會有震動回饋，這個沒有，用戶會懷疑有沒有切到。」</p </li <li <p <strong 與使用者期待一致</strong ：根據使用者的心智模型，這個結果不合理。例如：「下拉重新整理是行動端的共識手勢，這頁完全沒反應，使用者會反覆重試。」</p </li <li <p <strong 與規格或文件一致</strong ：行為跟 PRD、設計稿、API 文件說的不一樣。例如：「設計稿標示錯誤訊息要顯示在欄位下方，現在跳的是頂部 toast，視覺設計師的意圖沒有被實作。」</p </li <li <p <strong 與自身一致</strong ：同一個產品裡，同功能的兩個入口行為不一樣。例如：「從首頁進入的商品頁可以加入收藏，從搜尋結果進入的同一個商品頁，收藏按鈕是灰的——同一個功能，兩個入口表現不同。」</p </li <li <p <strong 與合理性或目的一致</strong ：這個結果對業務邏輯說不通。例如：「訂單取消後，狀態顯示『已完成』——這對客服和財務都會造成誤判，跟系統的核心業務目的相衝突。」</p </li </ul <p 不是每個 bug 都要對到六個參照。通常一個就夠了，重點是<strong 你能說出來</strong 。</p <h2 怎麼用</h2 <p 探索測試時，帶著這組判準在腦子裡跑，每當你對一個行為有疑慮，就自己問一遍：「這跟什麼不一致？」</p <p 這個習慣有兩個實際效果。</p <p 第一，它把模糊的不安轉化成可以寫進報告的具體描述。「我覺得這個頁面好像有點問題」→「這個輸入框的錯誤狀態和其他三個輸入框的樣式不一樣，不一致」。前者被關掉，後者被修掉。</p <p 第二，它讓你在「這是 feature 不是 bug」的爭論裡站得住腳。當你能指出這個行為跟哪個參照衝突——規格、設計稿、歷史版本、或另一個入口的行為——討論就從「你覺得 vs 我覺得」，變成「這個參照成不成立」。爭論的焦點從你的主觀感覺，轉移到可以查的事實。</p <p 這不是說判準就是最終裁決。有時候規格是錯的，有時候歷史行為本來就有問題。但判準讓你有辦法<strong 開口</strong ，讓對話發生。</p <h2 帶得走</h2 <ul <li <p 說不清楚「為什麼是 bug」，通常不是感覺錯了，而是參照點還沒說出口。</p </li <li <p 把「怪怪的」換成「跟什麼不一致」：歷史行為、可比產品、使用者期待、規格文件、自身一致性、業務合理性，六個方向任選一個說清楚。</p </li <li <p 探索時帶著這組判準，每個疑慮都問一句「這跟什麼不一致？」——模糊不安就會變成可以寫進報告、可以在討論裡站住腳的具體判斷。</p </li </ul <p </p