Leaked Bug trong quản lý phần mềm . Độ ưu tiên và nghiêm trọng trong quản lý bug

I. Leaked Bug trong kiểm thử phần mềm

Có một thực tế hết sức phũ phàng mà hầu hết các kỹ sư kiểm thử phần mềm đều gặp phải đó là gần như chắc chắn bạn không bao giờ tìm hết tất cả các lỗi của sản phẩm phần mềm. Bạn đã nắm rất kỹ, rất có kinh nghiệm trong kiểm thử chức năng hay kiểm thử tự động, đã test rất kỹ trước khi bàn giao nhưng vẫn bị khách hàng tìm thấy trong quá trình sử dụng.

1. Một số vấn đề mà tester thường xuyên gặp phải

• Sau khi kiểm thử một Website/Application cho khách hàng , chỉ yêu cầu test những chức năng của Website đó. Tôi dùng cả 2 kỹ thuật Function Testing và Automation Testing, cover được những testcase chính và đã pass tất cả. Những case khác, tôi đã thử tất cả các trường hợp xảy ra và tìm được rất nhiều bug. Khi tất cả các bug này được fix và thực hiện kiểm thử chấp nhận cũng đã pass. Sản phẩm được bàn giao cho khách hàng và nhận được feedback, tôi mới ngạc nhiên vì có rất nhiều bug từ người dùng.
• Nghiên cứu, đọc và thực hiện lại các mô tả lỗi của khách hàng để tìm kiếm nguyên nhân. Tôi mới thấy rằng, cách suy nghĩ, sử dụng, tương tác với sản phẩm phần mềm của người dùng cuối khác nhiều so với suy nghĩ của người phát triển phần mềm.

Vì sự chủ quan đảm bảo tất cả các chức năng hoạt động đúng như thiết kế mà vô tình quên đi những thói quen người dùng, những tương tác khác ( không có trong thiết kế ) vô tình tạo ra lỗi. Hoặc có thể tại thời điểm này, các chức năng của phần mềm hoạt động hoàn toàn đúng và chính xác nhưng ở một số trạng thái, luồng dữ liệu và điều khiển vẫn có một số đụng độ với webserver hay hệ điều hành, trình duyệt,... gây ra lỗi không đáng có.

2. Một số lưu ý dành cho tester

• Kiểm thử phần mềm phải luôn đứng và suy nghĩ như một người dùng thực sự, để mindset của bạn giải phóng bởi những ràng buộc cũng như lối tư duy “ Biết quá nhiều” của những nhà phát triển phẩn mềm.

• Kiểm thử phần mềm luôn làm giàu bộ testcase của bạn. Từ những case đơn giản, trực quan nhất đến các case dự đoán là sẽ tiềm ẩn nhiều bug nhất. Từ tình huống đến dữ liệu kiểm thử phải có tính hệ thống và hướng đến người dùng.
• Kiểm thử viên phải luôn note lại cho mình những trường hợp mà người dùng gặp phải, những case lạ, những phát hiện mới mẻ trong quá trình tìm bug sẽ giúp bạn có kinh nghiệm hơn,testcase phong phú và chất lượng hơn. Đó là sự tích góp, năng nhặt chặt bị để vào vai người sử dụng một cách tròn trĩnh và xuất thần.

II. Độ ưu tiên và độ nghiêm trọng 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.

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,...
• 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

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.

Có một thực tế không lấy gì vui vẻ 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 “dìm hàng” chúng ta 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 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à độ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

Thế 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)? Quá dễ, 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. Đú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. Quá tuyệt đúng không nào. 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 thằng bạn 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 đó”.

III. Tham khảo

https://voer.edu.vn/c/loi-bug-la-gi/4c771e16/32455ae1 http://www.careerride.com/testing-bug-leakage-and-bug-release.aspx https://sites.google.com/site/trangwebbanhoa/classroom-news/thisweekisscienceweek