Phần 1: Độ ưu tiên và độ nghiêm trọng của 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à những khái niệm cơ bản trong quản lý bug. Nó đã trở nên quá quen thuộc và phổ biến, tuy nhiên đôi khi chúng ta vẫn nhầm lẫn và 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ù độ ưu tiên và độ nghiêm trọng của bug không phải là những yếu tố quan trọng nhất, nhưng một khi xác định một cách đúng đắn sẽ giúp chúng ta làm việc hiệu quả, tiết kiệm thời gian, có thể đánh giá đúng tiến độ cũng như chất lượng của sản phẩm.

Mặc dù log một bug hoàn chỉnh sẽ phải liệt kê đầy đủ cả độ nghiêm trọng và mức độ ưu tiên của bug, tuy nhiên nhiều công ty chỉ sử dụng chỉ một, thường là mức độ ưu tiên.

1. Độ nghiêm trọng

Mức độ nghiêm trọng của một 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:

• Critical - Mức độ nghiêm trọng: Những lỗi nghiêm trọng khiến người dùng không thể sử dụng được ứng dụng như hệ thống sập, dữ liệu bị mất, ứng dụng không cài đặt được...
• Major - Mức độ cao: Chức năng chính của sản phẩm không hoạt động
• Medium - Mức độ trung bình: Sản phẩm hoặc ứng dụng hoạt động không đáp ứng tiêu chí nhất định hoặc vẫn còn bộc lộ một số hành vi không mong muốn, tuy nhiên các chức năng khác của hệ thống không bị ảnh hưởng.
• Low - Mức độ thấp: Lỗi xảy ra hầu như không ảnh hưởng gì đến chức năng, nhưng vẫn là lỗi và vẫn cần được sửa. Ví dụ như các lỗi về sai text, sai vị trí button,

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 là 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ử, việc đánh giá đúng độ nghiêm trọng của bug cũng sẽ gây được sự chú ý và tăng cơ hội bug đó được sửa.

2. Độ ưu tiên

Độ ưu tiên của bug xác định thứ tự sửa bug. Thực tế thì đội phát triển không thể fix hết tất cả các bug của sản phẩm cùng 1 lúc, do vậy sẽ cần phải dựa vào độ ưu tiên của bug để xác định bug nào sửa trước, bug nào sửa sau.

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. Thông thường mức độ nghiêm trọng của bug được chia thành 3 mức cơ bản nhất:

• High: Bug phải được sửa ngay lập tức sau khi phát hiện bug
• Medium: Bug có thể được sửa trong lần cập nhật phiên bản sau
• Low: Bug không cần sửa ngay, có thể sửa sau khi các bug High và Medium đã được sửa hết

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. Nó còn tùy thuộc vào nhiều yếu tố. Giả sử chúng ta tìm được một bug làm sập hệ thống hoặc chức năng chính không hoạt động. Đáng ra bug này sẽ phải được sửa ngay lập tức nhưng để làm sập hệ thống thì phải trải qua quá nhiều bước hoặc 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 đó và khả năng người dùng gặp phải lỗi đó là rất thấp. Vì thế nên, ở thời điểm đó độ ưu tiên của bug làm sập hệ thống chưa chắc bằng độ ưu tiên của một bug sai text nhỏ khác.

3. Một số ví dụ về priority và serverity

• High priority, high severity bug: Có lỗi xảy ra trên các chức năng cơ bản của ứng dụng và người dùng không thể sử dụng được hệ thống. Ví dụ: Khi đăng nhập vào một hệ thống, lỗi "Run time error" hiển thị trên trang web và người dùng không thể thực hiện được bất cứ thao tác nào nữa. Bug này được thể hiện là đường màu đỏ trên ảnh.
• High Severity – Low Priority bug: Điều này xảy ra khi các lỗi gây ra vấn đề lớn, nhưng chỉ xảy ra với 1 số điều kiện hoặc tình huống mà thực tế rất hiếm gặp. Bug này sẽ được sửa nhưng không cần sửa ngay lập tức. Ví dụ, khách hàng sử dụng các trình duyệt rất cũ và không thể tiếp tục đặt hàng trực tuyến được. Vì số lượng khách hàng sử dụng trình duyệt phiên bản cũ cũ là rất thấp, nên nó không phải là bug có độ ưu tiên cao. Bug này được thể hiện là đường màu hồng trên ảnh
• High Priority – Low Severity bug: Bug sẽ được sửa ngay nhưng không ảnh hưởng đến các chức năng khác của hệ thống. Ví dụ: Logo hoặc tên của công ty không được hiển thị trên trang web. Bug này phải được sửa càng sớm càng tốt mặc dù nó có thể không gây ra nhiều thiệt hại. Đường màu xanh biển thể hiện chính xác loại bug này.
• Low Priority – Low Severity bug: Loại bug này được thể hiện bằng màu xanh lá cây như trên hình. Lỗi không ảnh hưởng đến chức năng của hệ thống nhưng vẫn không đáp ứng được các tiêu chuẩn ở mức độ thấp. Ví dụ: Không có nhiều người quan tâm và xem trang chính sách quyền riêng tư trên một website bất kỳ, và việc trang này tải rất chậm cũng không ảnh hưởng quá nhiều đến người sử dụng. Bug này sẽ được xếp vào loại Low Priority – Low Severity.

4. Chọn độ nghiêm trọng và độ ưu tiên của bug chính xác

Dưới đây là những gợi ý mà tester cần chú ý để chọn chính xác độ nghiêm trọng và độ ưu tiên của bug:

• Hiểu và nắm chắc khái niệm độ ưu tiên và độ nghiêm trọng của bug, tránh nhầm lẫn và sử dụng thay thế cho nhau.
• Luôn luôn chọn mức độ nghiêm trọng dựa trên các vấn đề sẽ ảnh hưởng đến ưu tiên của nó.
  Trên thực tế là việc xác định độ nghiêm trọng của bug không hẳn lúc nào cũng mang tính chất 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. 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 bug đối với sản phẩm cũng như người dùng như thế nào như xảy ra trên nhiều môi trường nào; tính lặp đi lặp lại của bug; 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. Từ đó có thể lựa chọn độ ưu tiên của bug một cách hợp lý.
• Hiểu chức năng của hệ thống hoạt động như thế nào, phân tích, suy luận và hiểu kịch bản kiểm thử hoặc trường hợp kiểm thử trên thực tế sẽ ảnh hưởng như thế nào đến người sử dụng. Điều này cần rất nhiều sự hợp tác và tương tác với đội phát triển, trưởng nhóm test, trưởng nhóm phát triển... Trong các cuộc trao đổi đó bạn cũng cần phải tính đến yếu tố mất bao nhiêu thời gian để sửa các bug đó dựa vào độ phức tạp và thời gian xác nhận bug.
• Độ ưu tiên và độ nghiêm trọng của bug có thể sẽ khác nhau ở từng thời điểm và giai đoạn phát triển sản phẩm.

Kết luận

Cả mức độ nghiêm trọng và mức độ ưu tiên đều là hai thuộc tính của một bug mà chúng ta cần phải cung cấp trong mỗi report của bugs. Vì vậy, là một QA/ tester chúng ta cần nắm rõ được sự khác biệt giữa chúng để tiết kiệm thời gian, công sức hay trên hết là để đánh giá đúng tiến độ cũng như chất lượng của sản phẩm.

Phần 1: Các mức độ kiểm thử (Test Levels)

Kiểm thử Đơn vị (Unit Testing):

• Unit Testing là việc kiểm thử ở mức độ thấp nhất (các phương thức – method, hàm – function, lớp – class trong mã nguồn). Nhằm đảm bảo các thành phần trên hoạt động đúng như yêu cầu. Việc kiểm tra ở mức độ này thường do chính các Lập trình viên (Developer) thực hiện trong quá trình mã hóa (coding, implement).
• Một mô hình thường được ứng dụng với Unit Testing là Phát triển theo định hướng kiểm thử (Test-Driven Development). Trong đó, các unit test được viết trước dựa theo yêu cầu với kết quả trả về ban đầu là sai (false). Mã nguồn sẽ được viết sau và được kiểm tra tự động bằng các unit test. Việc phát triển được hoàn thành khi tất cả các unit test trả về kết quả đúng (true).
• Trong một số tài liệu chuyên về Kiểm thử phần mềm như ISTQB (phiên bản 2007), khái niệm Unit Testing được hiểu là Component Testing. Lý do là các công việc trên được thực hiện bởi Lập trình viên. Các tài liệu trên phân loại dưới quan điểm của một Kiểm thử viên.

Kiểm thử Thành phần (Component Testing, Module Testing):

• Là việc kiểm thử các gói chức năng (module, component) riêng lẻ. Không phụ thuộc đến các chức năng, thành phần khác trong hệ thống.
• Kiểm thử Tích hợp (Intergration Testing):
• Là việc kiểm thử nhằm xem xét các vấn đề có thể xảy ra khi hai hoặc nhiều Thành phần (component, module) của hệ thống tương tác với nhau.

Kiểm thử Hệ thống (System Testing):

• Là mức độ kiểm thử toàn bộ các chức năng của hệ thống phần mềm. Bao gồm tất cả các thành phần tương tác với nhau, và hoạt động trong môi trường giống như môi trường thực tế (hệ điều hành, cơ sở dữ liệu, kết nối mạng, khả năng tương thích với các phần mềm khác, …).
• Bên cạnh đó, Kiểm thử Hệ thống cũng chú ý đến vấn đề bảo mật, thân thiện, khả năng đáp ứng, tốc độ thực hiện của hệ thống phần mềm.

Kiểm thử Chấp nhận (Acceptance Testing, User Acceptance Testing):

• Mức độ này được thực hiện bởi phía người dùng với một nhóm độc lập với nhóm phát triển. Mục đích của giai đoạn này là kiểm tra, đánh giá phần mềm có đáp ứng được các yêu cầu của người dùng đã đề ra hay không? Có thể triển khai cho công việc thự tế của người dùng hay không.
• Việc được người dùng chấp nhận sẽ đánh dấu cho sự kết thúc của giai đoạn phát triển, mở ra giai đoạn triển khai, bảo trì và nâng cấp phần mềm.