Đánh giá mức độ nghiêm trọng và độ ưu tiên 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) cũng không quá xa lạ, đặc biệt là trong quản lý bug. Hai khái niệm trên đã trở nên quá quen thuộc và phổ biến đến nỗi chúng ta hầu như không phân biệt được ý nghĩa cũng như sự khác nhau giữa hai khái niệm đó. 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.

Mức độ ưu tiên xác định thứ tự mà chúng ta nên giải quyết một Bug. Chúng ta có nên sửa nó ngay bây giờ, hay nó có thể có thể để sau được không? Trạng thái ưu tiên này được xác định bởi kỹ sư kiểm thử để người lập trình có thể sắp xếp khoảng thời gian sửa lỗi vào giai đoạn nào cho phù hợp. Nếu bug có mức ưu tiên cao thì người lập trình phải khắc phục sớm nhất. Mức độ ưu tiên được xác định dựa trên yêu cầu của khách hàng. Ví dụ: Nếu tên công ty sai chính tả trong trang chủ của trang web, thì mức độ ưu tiên cao và mức độ nghiêm trọng thấp nhưng vẫn khắc phục sớm. Độ ư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

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. Vậy chúng ta sẽ dựa vào đâu để xác định độ ưu tiên? Bug nào sửa trước bug nào sửa sau (hoặc không sửa)? Đơn giản, dựa vào độ 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. Điều này Đúng…nhưng không phải lúc nào cũng đúng. 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 sau đó, độ ưu tiên của bug đó được điều chỉnh xuống thấp trong khi con bug bắt lỗi chính tả lại được đánh giá có độ ưu tiên cao để sửa. Điều này hoàn toàn dễ hiểu bởi vì “ 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 để tái hiện bug đó bạn phải trải qua vài rất nhiều 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 đó”. Suy cho cùng đó là một quyết định liên quan đến kinh doanh và hầu như chúng ta không thể thay đổi được quyết định đó. Xác định độ ưu tiên được khuyến khích đối với kỹ sư kiểm thử nhưng không phải bắt buộc. Đó là lí do tại sao ở một số dự án thậm chí kỹ sư kiểm thử được yêu cầu không xác định độ ưu tiên cho con bug và độ ưu tiên chỉ được xác định sau buổi họp đánh giá bug. Điều này cũng không có gì là vô lí.

Đó là phạm vi mà lỗi có thể ảnh hưởng đến phần mềm. Nói cách khác, nó định nghĩa tác động mà một khiếm khuyết nhất định có trên hệ thống. Ví dụ: Nếu ứng dụng hoặc trang web gặp sự cố khi nhấp vào liên kết từ xa, trong trường hợp này, việc nhấp vào liên kết từ xa bởi người dùng rất hiếm, nhưng tác động của ứng dụng bị lỗi nghiêm trọng. Vì vậy, mức độ nghiêm trọng là cao, nhưng ưu tiên là thấp. 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

Tương tự mức độ ưu tiên, mức độ nghiêm trọng 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 xác định được độ nghiêm trọng của con bug giúp người 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 là chưa đủ để đánh giá tình hình. Việc đội kiểm thử tìm được 50 con 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 con 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.

Có một thực tế là việc xác định độ nghiêm trọng của con bug không hẳn lúc nào cũng mang tính chất trắng-đen và tuyệt đối. Sẽ không có gì ngạc nhiên nếu chúng ta cho rằng vấn đề này là nghiêm trọng trong khi chủ sản phẩm, nhà quản lý dự án lại không nghĩ như vậy. Không hẳn là họ đang cố tình làm vậy mà cũng có thể cách chúng ta cung cấp thông tin không thể hiện được đầy đủ mức độ nghiêm trọng của vấn đề. Hãy phân tích và cung cấp thêm thông tin để cho thấy tác động nghiêm trọng của con bug đối với sản phẩm cũng như người dùng cuối như thế nào nếu xảy ra Ví dụ: xảy ra trên nhiều môi trường; lặp đi lặp lại; có khả năng ảnh hưởng đến các thành phần, chức năng khác; hình ảnh thương mại của công ty v.v. Và dĩ nhiên, nếu vấn đề không thực sự nghiêm trọng, thì cần phải xem xét lại. Việc hiểu rõ sản phẩm, người dùng cùng khả năng phân tích, suy luận sẽ giúp người kiểm thử làm tốt khâu này.

Trong báo cáo lỗi, mức độ nghiêm trọng và mức độ ưu tiên thường được điền bởi người viết báo cáo lỗi, nhưng nên được cả nhóm xem xét có thể được xác định dựa trên các tiêu chí sau:

• Độ nghiêm trọng cao - Lỗi ưu tiên cao

Ví dụ như trên một trang web Thương mại điện tử, mỗi khách hàng nhận được thông báo lỗi trên mẫu đặt phòng và không thể đặt hàng, hoặc trang sản phẩm ném phản ứng Lỗi 500.

• Mức độ nghiêm trọng cao - Lỗi ưu tiên thấp

Điều này xảy ra khi lỗi gây ra các vấn đề lớn, nhưng nó chỉ xảy ra trong điều kiện hoặc tình huống rất hiếm, ví dụ như khách hàng sử dụng các trình duyệt cũ rất cũ không thể tiếp tục mua sản phẩm. Bởi vì số lượng khách hàng có trình duyệt rất cũ rất thấp, nên không phải là ưu tiên cao để khắc phục sự cố.

• Mức độ ưu tiên cao - Mức độ nghiêm trọng thấp

Điều này có thể xảy ra khi, ví dụ, logo hoặc tên của công ty không được hiển thị trên trang web. Điều quan trọng là phải khắc phục sự cố càng sớm càng tốt, mặc dù nó không gây ra nhiều thiệt hại.

• Mức độ ưu tiên thấp - Mức độ nghiêm trọng thấp

Đối với những trường hợp lỗi không gây ra thảm họa và chỉ ảnh hưởng đến số lượng khách hàng rất nhỏ, cả Độ nghiêm trọng và Mức độ ưu tiên đều thấp, ví dụ trang chính sách bảo mật mất nhiều thời gian để tải. Không nhiều người xem trang chính sách bảo mật và tải chậm không ảnh hưởng đến khách hàng nhiều.

Độ ưu tiên và độ nghiêm trọng chỉ là hai trong số rất nhiều thông tin quan trọng khác chúng ta cần phải cung cấp như môi trường của con bug, mức độ lặp đi lặp lại, các bước mô tả con bug, phạm vi của con bug v.v. Tuy nhiên, việc hiểu đúng về mức độ nghiêm trọng, độ ưu tiên của sản phẩm cho thấy người kiểm thử thực sự hiểu rõ và quan tâm đến chất lượng sản phẩm cũng như thể hiện sự chuyên nghiệp của một kỹ sư kiểm thử Hy vọng bài viết sẽ giúp mọi người hiểu rõ hơn về mức độ nghiêm trọng và ưu tiên trong quản lý bug.

Nguồn tham khảo: https://sites.google.com/site/trangwebbanhoa/classroom-news/dhanh-gia-do-uu-tien-cua-bugs http://istqbexamcertification.com/what-is-the-difference-between-severity-and-priority/ http://www.softwaretestinghelp.com/priority-and-severity/