Severity vs Priority(Độ nghiêm trọng vs Mức độ ưu tiên)

1.Severity và Priority là gì? Phân biệt ra sao?

Trong bức tranh toàn cảnh của Vòng đời kiểm thử phần mềm (Software Testing Lifecycle – STLC), việc phát hiện ra lỗi (Bug/Defect) mới chỉ đóng góp 50% vào thành công của quy trình đảm bảo chất lượng. 50% còn lại phụ thuộc hoàn toàn vào khâu phân loại, định lượng và phân bổ nguồn lực để xử lý lỗi đó. Dưới áp lực khắc nghiệt về thời hạn bàn giao (Deadline) và ngân sách giới hạn của các dự án phần mềm thực tế, đội ngũ phát triển không thể cùng một lúc sửa toàn bộ hàng trăm lỗi xuất hiện trong hệ thống.

Để giải quyết bài toán tối ưu hóa nguồn lực này, hai chỉ số định lượng cốt lõi ra đời: Severity (Độ nghiêm trọng) và Priority (Mức độ ưu tiên). Đây là hai góc nhìn chiến lược giúp toàn bộ tập thể dự án trả lời hai câu hỏi mang tính sinh tử:

• Lỗi này gây thiệt hại nặng nề đến đâu về mặt cấu trúc kỹ thuật và sự vận hành của phần mềm? (Severity)

• Lỗi này bắt buộc phải được lập trình viên tiến hành sửa chữa gấp đến mức nào để phục vụ cho các mục tiêu kinh doanh và lộ trình ra mắt sản phẩm? (Priority)

Trong kiểm thử phần mềm, Severity (Độ nghiêm trọng) và Priority (Độ ưu tiên) là hai thuộc tính bắt buộc phải có khi tạo báo cáo lỗi (Bug Report). Dù thường đi chung với nhau, chúng đo lường hai khía cạnh hoàn toàn khác biệt.

1. Severity (Độ nghiêm trọng – Góc nhìn kỹ thuật)

• Bản chất: Đo lường mức độ ảnh hưởng của lỗi đến hệ thống phần mềm. Lỗi này làm hỏng tính năng nặng đến mức nào?

• Ai đánh giá: Kiểm thử viên (Tester).

• Tiêu chí: Dựa trên kỹ thuật và đặc tả yêu cầu (SRS). Lỗi làm sập app (Crash) chắc chắn Severity rất cao, lỗi sai chính tả thì Severity rất thấp.

2. Priority (Độ ưu tiên – Góc nhìn nghiệp vụ / kinh doanh)

• Bản chất: Đo lường mức độ khẩn cấp cần phải sửa lỗi. Lỗi này phải được sửa ngay bây giờ hay để sau mới sửa?

• Ai đánh giá: Quản lý dự án (Project Manager), Product Owner hoặc Khách hàng.

• Tiêu chí: Dựa trên nhu cầu kinh doanh, thời hạn phát hành (Deadline) và trải nghiệm người dùng thực tế.

Ví dụ kinh điển để hiểu sự khác biệt

Sự khác biệt giữa hai khái niệm này được thể hiện rõ nhất qua hai trường hợp thực tế sau:

• Trường hợp 1: Lỗi Severity THẤP nhưng Priority CAO

  • Tình huống: Logo công ty trên trang chủ bị viết sai chính tả (ví dụ: viết thành “Amazom” thay vì “Amazon”).

  • Vì sao: Severity Thấp vì nó không làm hỏng tính năng mua sắm hay đăng nhập của app. Nhưng Priority Cao vì nó đập ngay vào mắt khách hàng, làm mất uy tín công ty và phải sửa ngay lập tức trước khi ra mắt.

• Trường hợp 2: Lỗi Severity CAO nhưng Priority THẤP

  • Tình huống: Lỗi làm sập hệ thống (Crash) ở mục “Báo cáo tài chính năm 2020” nằm sâu trong phần cài đặt phụ.

  • Vì sao: Severity Cao vì hệ thống bị sập hoàn toàn (Crash). Nhưng Priority Thấp vì chẳng có ai vào xem mục báo cáo của năm cũ ở thời điểm này, team có thể để lại sửa sau.

Bảng tóm tắt nhanh:

2 Khái niệm, bản chất và phân cấp tiêu chuẩn của Severity và Priority:

A. Bug Severity (Độ nghiêm trọng của lỗi)

• Khái niệm: Bug Severity là chỉ số đo lường mức độ tác động kỹ thuật hoặc mức độ tàn phá của lỗi lên cấu trúc mã nguồn, độ ổn định của hệ thống, tính toàn vẹn của cơ sở dữ liệu và khả năng duy trì các luồng xử lý nghiệp vụ.

• Căn cứ và Đơn vị đánh giá: Chỉ số này do Kiểm thử viên (QC/Tester) chủ động phân tích và gán giá trị, dựa trên tài liệu đặc tả yêu cầu phần mềm (SRS), mức độ sụp đổ của chức năng và khả năng có hay không có giải pháp khắc phục tạm thời (Workaround).

• Các mức phân cấp tiêu chuẩn (Tương thích chuẩn ISTQB/ISO):

  1. Critical / Blocker (Rất nghiêm trọng): Lỗi làm sập toàn bộ hệ thống (System Crash), đứt gãy luồng xử lý chính (Core Business Workflow), gây mất mát dữ liệu nghiêm trọng, hoặc làm tắc nghẽn toàn bộ hoạt động kiểm thử (ngăn không cho QC tiếp tục thực thi các test cases khác).

  2. Major (Nghiêm trọng): Chức năng chính của hệ thống bị lỗi nặng, trả về kết quả tính toán sai lệch hoàn toàn so với tài liệu SRS và hoàn toàn không có giải pháp tạm thời (No Workaround) để người dùng có thể hoàn tất công việc.

  3. Minor (Trung bình): Chức năng phụ bị lỗi hoặc một phần của tính năng chính bị ảnh hưởng nhưng hệ thống vẫn cung cấp một giải pháp tạm thời (Workaround) giúp người dùng lách qua lỗi để hoàn thành quy trình.

  4. Low / Trivial (Thấp): Lỗi nhỏ về mặt thẩm mỹ giao diện (UI/UX), sai chính tả, lệch khoảng cách pixel, phông chữ không đồng nhất, không gây ảnh hưởng đến bất kỳ logic tính toán hay luồng xử lý dữ liệu nào của hệ thống.

B. Bug Priority (Mức độ ưu tiên của lỗi)

• Khái niệm: Bug Priority là chỉ số đo lường tầm quan trọng và độ khẩn cấp cần phải tiến hành sửa chữa lỗi dưới góc độ tiến độ dự án, mục tiêu kinh doanh, hình ảnh thương hiệu, hoặc trải nghiệm chung của người dùng cuối.

• Căn cứ và Đơn vị đánh giá: Chỉ số này do Quản lý dự án (Project Manager – PM), Chủ sản phẩm (Product Owner – PO) hoặc Trưởng nhóm kỹ thuật (Tech Lead) quyết định sau khi cân nhắc bối cảnh tổng thể của dự án.

• Các mức phân cấp tiêu chuẩn:

  1. High (Cao / Khẩn cấp): Lỗi bắt buộc phải được lập trình viên tiến hành sửa chữa ngay lập tức trong bản vá khẩn (Hotfix) hoặc trong đợt cập nhật sớm nhất. Nếu chưa sửa, sản phẩm tuyệt đối không được phép phát hành (Go-Live).

  2. Medium (Trung bình): Lỗi cần được xếp lịch sửa chữa trong đợt cập nhật định kỳ tiếp theo của chu kỳ phát triển (Sprint/Release).

  3. Low (Thấp): Lỗi không gấp, có thể thong thả sửa chữa khi đội ngũ phát triển đã hoàn thành xong các nhiệm vụ quan trọng khác hoặc chuyển sang đợt bảo trì cuối năm.

3. Ma trận kết hợp 4 kịch bản (Severity vs Priority)

Trong thực tế sản xuất phần mềm, Severity và Priority không phải lúc nào cũng tỉ lệ thuận với nhau. Một lỗi có độ nghiêm trọng kỹ thuật rất cao không đồng nghĩa với việc nó phải được sửa ngay lập tức, và ngược lại, một lỗi kỹ thuật cực kỳ nhỏ đôi khi lại bắt buộc phải sửa trong vòng vài phút. Sự kết hợp giữa hai chỉ số này tạo ra 4 kịch bản ma trận thực tế rõ ràng:

Kịch bản 1: High Severity – High Priority (Độ nghiêm trọng Cao – Mức ưu tiên Cao)

• Bản chất: Lỗi kỹ thuật cực kỳ nặng xảy ra ngay trên luồng nghiệp vụ cốt lõi của ứng dụng, ảnh hưởng trực tiếp đến người dùng và làm ngưng trệ hoạt động kinh doanh.

• Ví dụ thực tế: Nút Thanh toán trên ứng dụng thương mại điện tử bị lỗi sập trang (Crash) khiến toàn bộ 100% khách hàng không thể hoàn tất đơn hàng và không thể trừ tiền.

• Hành động: Toàn bộ đội ngũ lập trình phải tạm dừng các công việc khác để tập trung ra bản sửa lỗi Hotfix và cập nhật ngay lên môi trường sản xuất.

Kịch bản 2: High Severity – Low Priority (Độ nghiêm trọng Cao – Mức ưu tiên Thấp)

• Bản chất: Lỗi kỹ thuật rất nặng khiến hệ thống bị sập hoàn toàn, nhưng trường hợp xảy ra lỗi lại rơi vào tình huống người dùng thực tế hầu như không bao giờ hoặc rất hiếm khi gặp phải.

• Ví dụ thực tế: Hệ thống bị sập hoàn toàn nếu người dùng chạy ứng dụng trên hệ điều hành cổ điển Windows 95, hoặc khi cố tình nhập một chuỗi ký tự đặc biệt dài 10.000 ký tự vào ô nhập số điện thoại.

• Hành động: Ghi nhận lỗi lên hệ thống quản lý nhưng hoãn việc sửa chữa sang các giai đoạn sau để ưu tiên thời gian cho các tính năng quan trọng hơn.

Kịch bản 3: Low Severity – High Priority (Độ nghiêm trọng Thấp – Mức ưu tiên Cao)

• Bản chất: Lỗi kỹ thuật rất nhỏ không làm ảnh hưởng đến logic chương trình hay cơ sở dữ liệu, nhưng lại gây tổn hại nghiêm trọng đến thương hiệu, uy tín hoặc hình ảnh doanh nghiệp trước công chúng.

• Ví dụ thực tế: Tên thương hiệu của công ty trên trang chủ bị viết sai chính tả (viết thành HealthyByte thay vì HealthyBITE), hoặc Logo của nhà tài trợ chính ở góc màn hình bị hiển thị sai màu nhận diện.

• Hành động: Lập trình viên phải tiến hành sửa lại ngay lập tức để bảo vệ hình ảnh doanh nghiệp trước khi chiến dịch truyền thông diễn ra.

Kịch bản 4: Low Severity – Low Priority (Độ nghiêm trọng Thấp – Mức ưu tiên Thấp)

• Bản chất: Lỗi nhỏ về mặt thẩm mỹ, nằm ở chức năng phụ hoặc trang phụ ít người truy cập, không gây ảnh hưởng gì tới quy trình trải nghiệm của người dùng.

• Ví dụ thực tế: Một icon ở tận góc chân trang (Footer) bị lệch 2 pixel, hoặc câu thông báo hướng dẫn ở trang Điều khoản sử dụng có phông chữ bị nhỏ hơn chuẩn 1 cỡ chữ.

• Hành động: Lập trình viên sẽ sửa khi nào có thời gian rảnh rỗi hoặc gom lại sửa một lượt ở bản cập nhật lớn cuối năm.

4. Các cạm bẫy tư duy cần tránh khi đánh giá Severity và Priority:

1. Thói quen “Lạm dụng mức Critical/Blocker”: Kiểm thử viên mới vào nghề thường có tâm lý cố tình đẩy Severity của tất cả các lỗi do mình tìm thấy lên mức Critical để gây sự chú ý và ép Lập trình viên phải sửa lỗi của mình trước. Điều này gây nhiễu loạn thông tin quản trị và làm mất uy tín của QC đối với đội ngũ dự án.

2. Cá nhân hóa mức độ ưu tiên dựa trên cảm xúc: QC tự ý gán Priority cao cho các lỗi giao diện nhỏ chỉ vì bản thân cảm thấy “ngứa mắt”, thay vì cân nhắc dưới góc độ tiến độ chung và mục tiêu kinh doanh của toàn dự án.

3. Không cập nhật lại Priority khi bối cảnh dự án thay đổi: Một lỗi có thể ban đầu ở Priority Thấp trong giai đoạn phát triển, nhưng khi sắp đến ngày ra mắt (Go-Live) hoặc chạy chiến dịch Marketing thì bắt buộc PM phải đẩy lên Priority Cao để xử lý gấp.

5.Bài học thực tế và giá trị chuyên môn :

• Việc hiểu sâu, phân định rạch ròi và vận dụng thành thạo hai chỉ số Bug Severity và Bug Priority khẳng định tư duy làm việc chuyên nghiệp, bao quát và chín chắn của một kỹ sư QC.

• Nó giúp chuyển hóa công việc kiểm thử từ hành vi “chỉ đi tìm lỗi” thuần túy thành hoạt động “quản trị rủi ro chất lượng” song hành cùng Project Manager. Việc phân loại chính xác giúp tối ưu hóa nguồn lực nhân sự, đẩy nhanh tốc độ khắc phục sự cố, từ đó đảm bảo sản phẩm phần mềm ra mắt đúng thời hạn với độ ổn định tối đa.

Vu Do

Xem tất cả bài viết của tác giả

Bài viết khác

Redis & Caching là gì?

Redis & Caching là gì? Hướng dẫn sử dụng Redis trong Go 1. Caching là gì? Vì sao cần cache khi đã có database? Caching (bộ nhớ đệm) là kỹ thuật lưu tạm dữ liệu thường được truy cập để có thể lấy lại nhanh chóng khi cần, thay vì phải thực hiện lại toàn […]

Đọc thêm

Database Migration là gì?

1. Database Migration là gì? Database Migration là quá trình quản lý và áp dụng những thay đổi đối với cấu trúc hoặc dữ liệu trong cơ sở dữ liệu theo từng phiên bản của ứng dụng. Trong quá trình phát triển phần mềm, yêu cầu nghiệp vụ thường xuyên thay đổi. Một bảng có […]

Đọc thêm

Bug Lifecycle & Bug Report

1.Bug Lifecycle & Bug Report là gì? Trong quản lý chất lượng phần mềm, Bug Lifecycle (Vòng đời của lỗi) và Bug Report (Báo cáo lỗi) là hai khái niệm cực kỳ quan trọng giúp kiểm thử viên (Tester) và lập trình viên (Developer) trao đổi, theo dõi và sửa lỗi một cách chuyên nghiệp. […]

Đọc thêm

Bun ORM là gì?

Bun ORM là gì? Hướng dẫn sử dụng Bun ORM với Go và PostgreSQL 1. Bun ORM là gì? Bun là một thư viện ORM dành cho ngôn ngữ Go, được thiết kế theo hướng SQL-first. Thay vì cố gắng che giấu hoàn toàn SQL phía sau các phương thức trừu tượng, Bun cho phép […]

Đọc thêm

Positive vs Negative Testing(Kiểm thử tích cực và Kiểm thử tiêu cực)

1.Positive vs Negative Testing là gì? Trong ngành công nghệ phần mềm, chất lượng sản phẩm không bao giờ là một khái niệm đơn chiều. Một ứng dụng được lập trình hoàn hảo trên lý thuyết vẫn có thể sụp đổ hoàn toàn ngay trong ngày đầu tiên phát hành nếu nó chỉ được chuẩn […]

Đọc thêm

Eloquent ORM

Eloquent ORM là gì? Hướng dẫn sử dụng Eloquent trong Laravel 1. Eloquent ORM là gì? Eloquent ORM là hệ thống Object-Relational Mapping (ORM) được tích hợp trong Laravel, một framework phát triển ứng dụng Web bằng PHP. Eloquent cho phép lập trình viên tương tác với cơ sở dữ liệu thông qua các class […]

Đọc thêm