Độ ưu tiên, độ nghiêm trọng của bug 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.

• Priority: còn gọi là độ ưu tiên của một con bug. Độ ưu tiên này chỉ ra sự quan trọng của con bug đó và đúng hơn là tầm ảnh hưởng(impact) của bug này đến với hệ thống. Đánh giá đúng độ ưu tiên cao hay thấp sẽ giúp cho người lập trình sản phẩm hay quản lý sản phẩm có thêm thông tin để quyết định sửa lỗi trước hay sau hay sửa vào giai đoạn nào là hợp lý. Đồng thời nó cũng giúp cho việc đánh giá chất lượng của phần mềm sau khi được đến với người sử dụng hay bán ra.

• Severity: cũng ám chỉ đến tầm ảnh hưởng của con bug nhưng thường là được đánh giá dựa vào ảnh hưởng(impact) của bug này đến với người sử dụng cuối. Cũng giống như Priority, Severity cũng rất quan trọng trong việc cung cấp thông tin đến những người liên quan và chất lượng sản phẩm nhìn chung.

1. Độ nghiêm trọng

Mức độ nghiêm trọng của một con bug thường chỉ mức độ tác động của con 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

Cũng nên lưu ý 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 con 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 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.

Tuy nhiên, 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. 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, dev lại không nghĩ như vậy. Đó có thể do 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 như 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, chúng ta cũng không có lý do gì để làm cho lớn chuyện. 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 chúng ta làm tốt khâu này.

2. Độ ưu tiên

Như chúng ta đã biết nếu đã là bug thì sẽ phải sửa. Tuy nhiên, có một thực tế là dev 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 đó, dev 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

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.

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)?

Chúng ta 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.

Tuy nhiên, nếu 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 con bug bắt lỗi chính tả của đồng nghiệp lại được đánh giá có độ ưu tiên cao để sửa.

Chúng ta buồn rầu, thất vọng, khó chịu và quyết phải hỏi cho ra lẽ và được giải thích rằng: “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 đó”. 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 đó.

Có một thực tế phải thừa nhận là kỹ sư kiểm thử chúng ta biết rất ít hay thậm chí không thể biết được khối lượng công việc của đội phát triển, chi phí của dự án cũng như những quyết định kinh doanh mang tính chiến lược của nhà đầu tư, quản lý dự án hay chủ sản phẩm. Điều đó cũng không có gì là quá tệ đối với một kỹ sư kiểm thử. Nó chỉ liên quan đến vai trò và trách nhiệm công việc của kỹ sư kiểm thử.

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ời kết

Trách nhiệm và vai trò của kỹ sư kiểm thử là cung cấp thông tin về chất lượng sản phẩm càng nhiều, càng chi tiết càng tốt cho các nhà quản lý dự án, cho chủ sản phẩm - những người sau đó sẽ đưa ra những quyết định kinh doanh cho sản phẩm dựa vào những thông tin đó.

Độ ư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 chúng ta 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ử.

Link bài viết tham khảo: https://www.guru99.com/the-unconventional-guide-to-defect-management.html