Severity Vs Priority Trong Báo Lỗi Là Gì?

Bài glossary ngắn này tôi phân biệt rõ hai khái niệm bằng bảng, làm rõ ai đặt giá trị nào, rồi đi qua đủ bốn tổ hợp High/Low kèm ví dụ thực tế. Nó bổ trợ cho bài bug life cycle — nơi bạn dùng đúng hai trường này khi mô tả lỗi.

Severity vs Priority — bảng phân biệt nhanh

Để dễ nhớ, hãy đặt hai khái niệm cạnh nhau theo từng tiêu chí:

Tiêu chí | Severity (mức nghiêm trọng) | Priority (độ ưu tiên)
Trả lời câu hỏi | Lỗi nặng tới đâu về kỹ thuật? | Lỗi cần sửa gấp tới đâu?
Bản chất | Tác động kỹ thuật lên hệ thống | Giá trị nghiệp vụ / thời gian
Ai đặt | Tester (người tìm ra lỗi) | PO / BA / Project Manager
Thường thay đổi? | Khá ổn định, gắn với lỗi | Có thể đổi theo bối cảnh, release
Ví dụ giá trị | Critical, Major, Minor, Trivial | High, Medium, Low

Nói ngắn gọn: severity trả lời "lỗi này tệ tới đâu", còn priority trả lời "sửa nó trước hay sau". Hai trục đánh giá khác nhau nên đừng đồng nhất chúng.

Severity (mức nghiêm trọng) là gì?

Severity là mức độ nghiêm trọng của lỗi xét về mặt kỹ thuật — lỗi ảnh hưởng tới chức năng và sự ổn định của hệ thống đến đâu. Đây là góc nhìn của tester: lỗi làm sập tính năng, sai dữ liệu, hay chỉ lệch hiển thị? Vì gắn với bản chất kỹ thuật, severity khá ổn định và do người tìm ra lỗi đánh giá.

Các mức severity thường gặp, từ nặng đến nhẹ:

Critical: hệ thống sập, mất dữ liệu, không thể tiếp tục dùng.

Major: một chức năng chính hỏng nhưng còn cách đi vòng (workaround).

Minor: lỗi nhỏ, ít ảnh hưởng tới việc dùng.

Trivial: lỗi vặt như sai chính tả, lệch màu, lệch vài pixel.

Nếu gặp thuật ngữ lạ khi đọc các mức này, bạn tra nhanh ở thuật ngữ kiểm thử.

Priority (độ ưu tiên) là gì?

Priority là mức ưu tiên xử lý lỗi — lỗi cần được sửa gấp tới mức nào xét theo nghiệp vụ, khách hàng và lịch release. Đây là góc nhìn quản lý: dù lỗi nặng hay nhẹ về kỹ thuật, có cần đưa vào sửa ngay trong sprint này không? Priority thường do PO, BA hoặc Project Manager quyết định và có thể thay đổi theo bối cảnh.

Các mức priority phổ biến:

High: phải sửa ngay, chặn release hoặc ảnh hưởng người dùng diện rộng.

Medium: nên sửa trong bản phát hành kế tiếp.

Low: sửa khi rảnh, không gấp.

Một lỗi Trivial nhưng nằm ngay logo trang chủ vẫn có thể bị đặt High priority vì ảnh hưởng hình ảnh thương hiệu — đó là lý do severity và priority không đi kèm cố định.

Ma trận Severity × Priority (ví dụ)

Vì là hai trục độc lập, ghép lại ta có bốn tổ hợp. Lấy bối cảnh hệ thống đặt phòng họp nội bộ của một công ty để minh họa:

Tổ hợp | Ý nghĩa | Ví dụ trên hệ thống đặt phòng họp
High severity – High priority | Lỗi nặng, phải sửa ngay | Bấm "Đặt phòng" làm sập trang, không ai đặt được phòng
High severity – Low priority | Lỗi nặng nhưng chưa cần sửa gấp | Xuất báo cáo lịch họp cả năm bị crash, nhưng tính năng này gần như không ai dùng
Low severity – High priority | Lỗi nhẹ nhưng cần sửa gấp | Sai chính tả tên công ty trên header mọi trang — phải sửa ngay vì lộ với khách
Low severity – Low priority | Lỗi nhẹ, sửa khi rảnh | Lệch 2px viền nút "Hủy" trên màn hình hiếm khi mở

Cặp đáng chú ý nhất là hai ô giữa: High severity – Low priority (lỗi nặng ở chỗ ít dùng) và Low severity – High priority (lỗi nhỏ ở chỗ "đập vào mắt"). Hiểu được hai tổ hợp này là bạn đã nắm vững khác biệt giữa severity và priority.

Muốn luyện phân loại lỗi bài bản trên dự án thật và được mentor review từng bug report, bạn tham khảo khóa Manual Testing của IT LEARN.