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

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