缺陷分級：Severity 不等於 Priority

缺陷分級：Severity 不等於 Priority 你提了一個 bug：後台的批次匯出功能在匯出超過一萬筆時直接崩潰。開發說：「優先級應該很低吧，這個功能沒幾個人用。」你回：「這可是 Severity Critical 啊。」兩個人都沒說錯，只是講的不是同一件事。 兩個常被混用的詞 Severity（嚴重度） 問的是：這個 bug 對功能本身造成多大的技術衝擊？ 它是客觀的。崩潰就是崩潰、資料遺失就是資料遺失，不因為有沒有人使用而改變事實。評估的責任在 QA：你最接近功能的技術層面，最清楚影響範圍。Severity 定了之後，在同一個版本迭代裡通常不太會變動。 Priority（優先級） 問的是：這個 bug 該多急著修？ 它是主觀的，由業務脈絡驅動。哪個功能正在上行銷活動、哪個用戶是大客戶、這週衝不衝版本——都會影響修復順序。評估的責任在 PM 或業務端，他們掌握的是商業判斷，不是技術判斷。Priority 會隨情況改變：下週沒人用的功能，可能因為大客戶突然投訴而從 P2 跳到 P0。 一句話拆清楚： Severity 是「傷多重」，Priority 是「多急救」。 兩個是獨立的軸，不互推。 高 Severity 低 Priority，低 Severity 高 Priority 看兩個例子： 案例一：後台批次匯出崩潰 只有 admin 用、每季才跑一次、生產現場只有兩個人知道這個功能。Severity 高（核心操作完全失效），但 Priority 低（影響範圍極小、使用頻率極低、有手動替代方案）。這個 bug 可能進下一個迭代，但不會擋這次上線。 案例二：首頁 logo 連結打錯網址 點下去跳到舊域名，使用者不會崩潰、資料不會遺失、頁面完全能操作。Severity 低（只是一個壞掉的超連結），但 Priority 高（每個進站的人都看得到、品牌形象直接受損）。這個 bug 可能在同一天就得修掉。 | | Severity 高 | Severity 低 | | | | | | Priority 高 | 核心支付流程崩潰 | 首頁 logo 連結錯 | | Priority 低 | 罕用後台功能崩潰 | 偏僻頁面的錯字 | P0 P2：把優先級講成可排程的刻度 P0 P2 是 Priority（優先級） 的刻度，不是 Severity 的刻度。QA 給出客觀的 Severity 判斷之後，PM 或團隊再綜合業務脈絡定出 Priority——「這個 bug 該多急著修」。Priority 常見的分法是三級： P0（阻斷） ：核心流程完全卡死、系統崩潰、嚴重資安漏洞（未登入即可存取他人資料）。一票否決，非修不可，通常當下就要 hotfix。 P1（嚴重） ：主要功能異常，但還有替代路徑可以繞開。例如購物車無法用信用卡付款，但還能用第三方支付。嚴重，但不是立刻停擺。這個版本內要修。 P2（輕微） ：錯字、樣式跑版、文案不一致、非核心流程的小異常。不影響功能使用。可以下版、進下個迭代、或轉 Known Issue。 同一個 bug，Severity 和 Priority 都要各填一個 ，填完才能做出合理的排程決策，而不是靠人各自解讀。 跟 PM 對齊與 Known Issue RD 說「這個來不及修」時，別默默接受，也別硬逼對方改，把 PM 拉進來三方評估：這個 bug 的 Severity 是多少、影響到哪些用戶路徑、不修的話風險是什麼。上不上線是業務決策，但決策要基於完整的風險資訊。 如果三方評估後決定帶著某個缺陷上線，記錄下來，轉為 Known Issue ： 在 issue tracker 明確標記為 known issue，附上風險評估。 設一個歸還期限（例如下個迭代必修）。 在上線記錄或 release note 中留存，避免未來有人再次回報、重複消耗排查時間。 沒記錄清楚的下場，我看過：某個設定開著的情況下，暫停中把 App 殺掉，重開後狀態判斷錯誤。這個問題前後兩個月被不同版本的測試重新發現兩次，開發兩次都判斷不修。不修的決定可以接受，問題是沒人把它記成已知問題，每次都有人重新發現、重新開單、再被標一次不修。 Known Issue 是有意識的取捨，前提是記錄清楚。