Short: Severity & Priority không có mối liên hệ gì cả.
—-
Long: 
Severity: Chỉ mức độ ảnh hưởng sẽ gây nên cho hệ thống (hoặc người dùng) khi có lỗi xảy ra. Các mức cơ bản:
– Critical
– Major
– Moderate
– Low (or Minor)

Priority: Định nghĩa thứ tự sẽ xử lý / fix lỗi đó. Lỗi có độ ưu tiên cao hơn sẽ được sửa trước. Các mức cơ bản:
– Priority 1 – Critical
– Priority 2 – High
– Priority 3 – Medium
– Priority 4 – Low

Có bạn nghĩ hai cái này có sự liên quan nhau, ví dụ lỗi có ảnh hưởng cao sẽ nên fix trước hoặc lỗi ảnh hưởng thấp sẽ có ưu tiên thấp nhưng không phải vậy. Mình sẽ có 4 ví dụ để cho thấy nó không liên quan.

1. High severity – High priority: Vd một lỗi về mua hàng không thưc hiện được, ảnh hưởng khá cao đến kinh doanh vì vậy độ ưu tiên cũng cao, cái này dễ hiểu 

2. Low severity – Low priority: Lỗi font chữ hơi to, hơi nhỏ, hơi mờ. Độ ảnh hưởng đến hệ thống và người dùng ít, họ vẫn sử dụng các chức năng được bình thường vì vậy ưu tiên thấp, cái này cũng hợp lý.

3. Low severity – High priority: Lỗi gì mà ảnh hưởng thấp, nhưng lại nên fix sớm? ví dụ một lỗi nào đó như banner bị méo / lệch – mà banner đó nằm ngay trang chủ ai vào cũng thấy, tuy nó không ảnh hưởng đến chức năng nhưng vẫn nên fix trước. Hoặc cty bạn làm về đào tạo ngoại ngữ, ở Title ghi sai chính tả, tuy không ảnh hưởng gì đến hệ thống nhưng cũng nên fix sớm, không để vậy lâu được.

4. High Severity, low priority: Lỗi nghiêm trọng, mà có thể để từ từ fix? Có thấy lấy vd như lỗi về game, game bạn có 20 level, ở level 18 nó bị crash/treo không chơi được. Đây là một lỗi khá nghiêm trọng tuy nhiên nhân biết để đạt dc level này đòi hỏi người chơi phải cày vài tháng nữa, vì vậy có thể set ưu tiên thấp xuống, tập trung fix các lỗi ở level 1,2,3.. trước tiên.

Việc set severity/priority phụ thuộc vào nhiều yếu tố như yêu cầu hệ thống, mong muốn khách hàng, kinh nghiệm tester. Việc set đúng không những giúp các lỗi được sửa nhanh chóng, đúng thứ tự ưu tiên mà còn giúp những người cấp cao hơn dễ đưa ra những quyết định liên quan đến chất lượng và thời gian dành cho những lỗi đó.

One Comment

  1. Pingback: Cách viết một bug report tốt – Sang Bui

Leave a Comment

Your email address will not be published. Required fields are marked *