Sự khác biệt Severity và Priority
Một lỗi vừa được tìm thấy. Tester bảo "nghiêm trọng lắm, app crash luôn". Dev liếc qua rồi nhún vai: "Crash thì crash, nhưng chỗ đó cả tháng chẳng ai đụng tới, để sau". Và thế là cuộc tranh cãi quen thuộc bắt đầu — lỗi này có thật sự gấp không? Phần lớn mâu thuẫn ấy không đến từ cái bug, mà đến từ việc cả hai đang nói về hai thứ khác nhau mà cứ tưởng là một.
Trong một bug report, Severity và Priority là hai trục đánh giá hoàn toàn độc lập — một bên đo mức độ tổn hại kỹ thuật, một bên đo thứ tự cần sửa theo lợi ích kinh doanh. Nhầm lẫn hai khái niệm này khiến đội ngũ sửa nhầm thứ tự, lãng phí thời gian vào lỗi ít người gặp, hoặc tệ hơn — để một lỗi nhỏ về mặt kỹ thuật nhưng bào mòn uy tín thương hiệu nằm im trong backlog. Phân biệt được hai trục này là kỹ năng nền tảng giúp một QA viết bug report mà cả dev lẫn PM đều tin tưởng.
Trong bài viết này, bạn sẽ nắm được:
- Định nghĩa chính xác của Severity và Priority, và vì sao chúng là hai trục độc lập.
- Ai là người quyết định mỗi giá trị, và giá trị nào thay đổi theo thời gian.
- Ma trận 2×2 với ví dụ thật từ ứng dụng ngân hàng để gán nhãn không còn lúng túng.
- Bộ tips để mỗi bug report của bạn nói đúng "mức độ" lẫn "độ gấp".
Severity và Priority là gì?
Hiểu đúng từ định nghĩa là cách duy nhất để hết nhầm. Hai khái niệm này trả lời cho hai câu hỏi khác nhau: "Lỗi này phá hỏng cái gì?" và "Khi nào thì phải sửa nó?".
SEVERITY — Mức độ nghiêm trọng
Severity đo lường tác động của bug đến chức năng của ứng dụng — thuần tuý ở khía cạnh kỹ thuật. Một lỗi làm app crash, mất dữ liệu hay chặn cả luồng nghiệp vụ thì nghiêm trọng, bất kể có bao nhiêu người gặp nó.
- Đo tác động kỹ thuật của bug lên chức năng hệ thống.
- Thường do QA Tester quyết định khi ghi nhận lỗi.
- Tập trung vào khía cạnh kỹ thuật, không quan tâm bối cảnh kinh doanh.
- Giá trị không thay đổi theo thời gian — lỗi nghiêm trọng thì nghiêm trọng dù sửa sớm hay muộn.
PRIORITY — Mức độ ưu tiên
Priority xác định thứ tự sửa bug dựa trên tác động kinh doanh — nó trả lời câu hỏi "cái nào nên sửa trước". Một lỗi có thể nhẹ về kỹ thuật nhưng cực gấp vì nó đập vào mắt khách hàng hoặc ảnh hưởng tới doanh thu.
- Xác định thứ tự sửa bug dựa trên tác động kinh doanh.
- Thường do Product Manager / Triage Team quyết định.
- Tập trung vào thời gian và tầm quan trọng đối với người dùng, thị trường.
- Giá trị có thể thay đổi theo tình huống — sát ngày release hay sau một sự cố truyền thông, độ ưu tiên có thể tăng vọt.
So sánh nhanh Severity và Priority
Đặt cạnh nhau, sự khác biệt giữa hai trục trở nên rõ ràng:
| Tiêu chí | Severity (Mức độ nghiêm trọng) | Priority (Mức độ ưu tiên) |
|---|---|---|
| Đo lường điều gì | Tác động kỹ thuật của bug đến chức năng | Thứ tự cần sửa dựa trên tác động kinh doanh |
| Góc nhìn | Kỹ thuật | Thời gian & tầm quan trọng |
| Ai quyết định | QA Tester | Product Manager / Triage Team |
| Tính ổn định | Không đổi theo thời gian | Có thể thay đổi theo tình huống |
| Câu hỏi trả lời | "Lỗi này phá hỏng cái gì?" | "Khi nào phải sửa nó?" |
Ma trận Severity × Priority với ví dụ thực tế
Vì là hai trục độc lập, bất kỳ tổ hợp nào cũng có thể xảy ra. Cách trực quan nhất để "gán nhãn" cho một bug là đặt nó vào ma trận 2×2. Dưới đây là bốn góc phần tư, minh hoạ bằng ứng dụng ngân hàng (Banking):
| High Priority (cần sửa gấp) | Low Priority (sửa sau) | |
|---|---|---|
| High Severity | 🚨 Nút "Đăng nhập" không hoạt động → toàn bộ app bị block, không ai dùng được. Vừa hỏng nặng về kỹ thuật, vừa phải sửa ngay. | 🔴 App không chạy được trên IE8 → lỗi nặng về kỹ thuật, nhưng rất ít user còn dùng trình duyệt cũ nên có thể xử lý sau. |
| Low Severity | ⚠️ Lỗi chính tả ở chữ "Chuyển khoản" ngay màn hình giao dịch → kỹ thuật chẳng hỏng gì, nhưng ảnh hưởng trực tiếp tới uy tín ngân hàng nên phải sửa gấp. | 🟡 Màu sắc trang Help không khớp theme → ảnh hưởng nhỏ, lại ở trang ít người truy cập, để dành cuối cùng cũng được. |
Bốn ô này chính là điểm hay gây nhầm nhất. Đáng chú ý là hai góc "lệch trục": một lỗi nhẹ về kỹ thuật vẫn có thể cực gấp (lỗi chính tả trên màn hình giao dịch), và một lỗi nặng về kỹ thuật lại không gấp (chỉ hỏng trên trình duyệt gần như không còn ai dùng).
Kinh nghiệm thực chiến. Khi phân vân giữa Severity và Priority, hãy tách bạch hai câu hỏi: "Về mặt kỹ thuật, lỗi này phá hỏng đến đâu?" để chấm Severity, và "Nếu không sửa ngay thì doanh nghiệp/người dùng chịu thiệt gì?" để đề xuất Priority. Là QA, bạn nắm chắc trục Severity; còn Priority hãy đề xuất kèm lý do kinh doanh rồi để PM/Triage Team chốt — đó mới là lúc bug report của bạn được tin tưởng.
Tips cho QA khi phân loại bug
- Luôn ghi rõ cả Severity và Priority trong mỗi bug report — đừng để trống một trục rồi để người khác tự suy diễn.
- Cân nhắc business context khi assign Priority — một lỗi nhỏ về kỹ thuật vẫn có thể là ưu tiên số một nếu nó chạm tới uy tín hay doanh thu.
- Áp dụng automated testing cho các case High Severity — những lỗi gây tổn hại nặng cần được giám sát tự động để không lọt lưới ở các lần release sau.
- Review và update Priority theo project timeline — vì Priority thay đổi theo tình huống, hãy rà lại nó khi tới gần release hoặc khi bối cảnh kinh doanh đổi.
Kết luận
Severity và Priority không phải hai cách nói của cùng một thứ, mà là hai trục độc lập: Severity đo lỗi phá hỏng cái gì về mặt kỹ thuật và do QA chốt, không đổi theo thời gian; Priority đo lỗi cần sửa khi nào theo lợi ích kinh doanh, do PM/Triage chốt và có thể thay đổi. Khi bạn quen tách bạch hai trục — và đặt mỗi bug vào đúng ô của ma trận 2×2 — những cuộc tranh cãi "lỗi này có gấp không" sẽ tự tan biến, thay bằng một bug report rõ ràng mà cả dev lẫn PM đều hiểu ngay.
Bạn đã từng gặp trường hợp nào khó phân biệt Severity vs Priority? Hãy chia sẻ kinh nghiệm để cộng đồng QA cùng học hỏi nhé!