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

> Khi báo lỗi, hai trường severity và priority hay bị điền lẫn lộn. 🙂 Nói gọn: severity là mức nghiêm trọng kỹ thuật của lỗi (lỗi phá vỡ hệ thống tới đâu), còn priority là mức ưu tiên xử lý (cần sửa gấp tới đâu theo nghiệp vụ và thời gian). Hai cái độc lập nhau, nên một lỗi hoàn toàn có thể nghiêm trọng mà chưa cần sửa ngay, hoặc ngược lại.

- **URL canonical**: https://itlearn.edu.vn/blog/severity-vs-priority
- **Published**: 2026-06-26T11:00:00+07:00
- **Modified**: 2026-08-05T22:04:50+07:00
- **Author**: Trung tâm IT Learn
- **Category**: Manual Testing (https://itlearn.edu.vn/blog/cat/manual-testing)
- **Reading time**: 6 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

 

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](/blog/bug-life-cycle-bug-report) — 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ử](/blog/thuat-ngu-kiem-thu/).

## 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](/newtester.html) của IT LEARN.

## Câu hỏi thường gặp

### Severity và Priority khác gì nhau?

Severity là mức nghiêm trọng kỹ thuật của lỗi — lỗi phá vỡ chức năng và sự ổn định của hệ thống tới đâu. Priority là mức ưu tiên xử lý — lỗi cần được sửa gấp tới mức nào theo nghiệp vụ và lịch release. Một cái nói lỗi "nặng tới đâu", cái kia nói "sửa trước hay sau".

### Lỗi severity cao priority thấp là gì?

Đó là lỗi nghiêm trọng về kỹ thuật nhưng chưa cần sửa gấp, thường vì nó nằm ở tính năng ít người dùng hoặc trường hợp hiếm gặp. Ví dụ chức năng xuất báo cáo cả năm bị crash, nhưng gần như không ai dùng, nên được xếp severity cao mà priority thấp, để xử lý sau.

### Ai quyết định priority của lỗi?

Priority thường do Product Owner, BA hoặc Project Manager quyết định, vì nó phản ánh giá trị nghiệp vụ, mức ảnh hưởng tới khách hàng và lịch phát hành. Tester có thể đề xuất, nhưng người nắm bức tranh sản phẩm và thời gian release mới là người chốt mức ưu tiên xử lý cuối cùng.

### Severity do ai đặt?

Severity do tester — người tìm ra lỗi — đánh giá, vì họ hiểu rõ lỗi tác động kỹ thuật tới hệ thống thế nào. Mức severity gắn với bản chất lỗi nên khá ổn định: lỗi làm sập hệ thống là Critical dù ở dự án nào, không phụ thuộc vào lịch release hay mong muốn nghiệp vụ.

### Ví dụ severity cao priority thấp?

Trên hệ thống đặt phòng họp nội bộ, chức năng xuất báo cáo lịch họp cả năm bị crash hoàn toàn — đó là lỗi severity cao vì phá vỡ tính năng. Nhưng vì gần như không nhân viên nào dùng báo cáo này, đội dự án đặt priority thấp và để sửa ở bản phát hành sau, ưu tiên các lỗi gấp hơn.