Độ ưu tiên (Priority) và Độ nghiêm trọng (Severity) trong quản lý Bug

Trong kiểm thử phần mềm thì hai khái niệm Độ ưu tiên (Priority) và Độ nghiêm trọng (Severity) là 2 khái niệm quen thuộc và phổ biến. Mặc dù hai yếu tố này không phải là yếu tố sống còn trong quản lý bug nhưng việc hiểu đúng sẽ giúp chúng ta tiết kiệm thời gian cũng như làm công việc hiệu quả hơn.

1. Độ nghiêm trọng Mức độ nghiêm trọng của 1 Bug thường chỉ mức độ tác động của Bug đó đến sản phẩm/ người dùng. Mỗi dự án hay sản phẩm có tiêu chí đánh giá độ nghiêm trọng khác nhau nhưng thông thường sẽ có 4-5 mức độ khác nhau từ nghiêm trọng nhất đến ít nghiêm trọng hơn:

• Mức độ 1: Hệ thống sập, dữ liệu bị mất, ứng dụng không cài đặt được v.v. • Mức độ 2: Chức năng chính của sản phẩm không hoạt động • Mức độ 3: Chức năng phụ của sản phẩm không hoạt động • Mức độ 4: Bug nhỏ, không quan trọng • (Mức độ 5): Yêu cầu cải tiến sản phẩm, thêm chức năng

Note: Việc định nghĩa mức độ nghiêm trọng phụ thuộc vào sản phẩm khác nhau, mang tính tham khảo và tương đối.

Việc xác định được độ nghiêm trọng của Bug, giúp nhà quản lí dự án, chủ sản phẩm có cái nhìn tốt hơn và thuận lợi hơn về tình hình chất lượng của sản phẩm. Số lượng bug chưa đủ để đánh giá tình hình. Việc đội kiểm thử tìm được 50 Bug trong 1 tháng cũng không nói lên nhiều về tình hình chất lượng của sản phẩm. Tuy nhiên, nếu biết được trong 50 Bug đó có đến hơn 1 nửa là bug với độ nghiêm trọng ở cấp độ 1 và 2 sẽ hữu ích hơn nhiều. Ngoài ra, với góc độ của kỹ sư kiểm thử, độ nghiêm trọng cũng giúp “quảng cáo” cho con bug của mình từ đó sẽ gây được sự chú ý của mọi người và tăng cơ hội con bug đó được sửa.

2. Độ ưu tiên Có một thực tế là đội phát triển khó có thể sửa hết tất cả bug một lượt cũng như không đáng để sửa hết tất cả các bug. Do đó, đội phát triển sẽ phải cần đến độ ưu tiên của con bug để biết được bug nào cần được sửa trước bug nào sau. Độ ưu tiên của con bug cũng thường được chia thành 3-4 cấp độ:

• Mức độ 1: Cao – Bug sẽ phải sửa ngay lập tức • Mức độ 2: Trung bình – Bug sẽ sửa trong bản cập nhật lần tới • Mức độ 3: Thấp – Bug không cần sửa trong bản cập nhật lần tới, có thể sửa nếu có thời gian

Note: Tương tự mức độ nghiêm trọng, mức độ ưu tiên cũng như ý nghĩa của chúng có thể sẽ khác nhau ở những sản phẩm, dự án khác nhau.

Việc đánh giá độ ưu tiên của Bug dựa trên độ nghiêm trọng của Bug. Bug nào nghiêm trọng nhất, tác động đến người dùng nhiều nhất thì sẽ được ưu tiên sửa trước. Bug nào ít nghiêm trọng hơn sẽ được sửa sau.

Tuy nhiên, trong một số trường hợp đặc biệt: Giả sử chúng ta tìm được một bug làm sập hệ thống. Chúng ta đánh giá mức độ nghiêm trọng ở Mức độ 1 (rất là nghiêm trọng) và độ ưu tiên 1 (cần được sửa gấp). Nhưng hôm sau, độ ưu tiên của bug đó được điều chỉnh xuống thấp trong khi Bug bắt lỗi chính tả được đánh giá có độ ưu tiên cao để sửa. Nguyên nhân là do: “Mặc dù bug đó làm sập hệ thống nhưng khả năng người dùng bị lỗi đó là rất thấp do để làm ra bug đó bạn phải trải qua vài chục bước hay bug đó chỉ xảy ra trên một môi trường cụ thể cũng như rất ít người dùng chạy sản phẩm trên môi trường đó”.

Một số kỹ sư kiểm thử mới làm thường hay chú trọng đến Priority mà quên đi Severity, chưa kể đến các một số bạn còn chưa nhận thức được rẳng 2 giá trị chỉ mang ý nghĩa đơn giản và không chú tâm đến việc đánh giá nó cho đúng. Tuy nhiên, 2 thuộc tính đều vô cùng quan trọng do các Bug đó có thể là rủi ro(risk) khi sản phẩm được giao(delivered) và việc xác định rủi ro này quyết đinh đến chất lượng của sản phẩm.

Rủi ro và độ ưu tiên thường được tính theo công thức: Risk Value = Probability x Impact Đô ưu tiên(priority) = Priority value(thuộc tính prioriry của bug) x Severity Value(thuộc tính severity của bug)

Thông thường, Bugs mang giá trị thuộc tính Priority thấp và đồng thời mang thuộc tính Severity cao: Những bugs này có ảnh hưởng rất lớn đến người sử dụng nhiều hơn là ảnh hưởng đến hệ thống, phần mềm hay các yêu cầu đặc tả phần mềm. Những bugs này thường phải được fix trước với tính urgent cao do nó có thể ảnh hưởng đến uy tín sản phẩm. Trong trường hợp 2 bugs có độ ưu tiên bằng nhau thì nên fix bug nào có Severity value cao hơn.

Hi vọng giúp ích cho các bạn làm kiểm thử phần mềm.