Severity
Mức độ ảnh hưởng của một defect lên hệ thống và nghiệp vụ, do QC đánh giá dựa trên hậu quả kỹ thuật. Nó khác với priority, tức thứ tự cần sửa trước sau.
Định nghĩa
Severity trả lời câu hỏi: nếu lỗi này xảy ra thì hệ thống hỏng tới mức nào. Nó nói về hậu quả, không nói về lịch sửa. Người đặt severity thường là QC, ngay lúc log defect, dựa vào cái họ vừa nhìn thấy.
Severity đo mức tàn phá của defect; priority đo mức gấp gáp phải sửa. Hai chuyện tách rời nhau.
Các mức thường dùng
| Mức | Nghĩa | Ví dụ |
|---|---|---|
| Critical | Hệ thống chết hoặc mất dữ liệu, không có cách nào đi vòng | Không đăng nhập được, trừ tiền mà không ghi nhận giao dịch |
| High | Chức năng chính sai, có thể đi vòng nhưng rất khổ | Tính sai tiền chiết khấu cho một nhóm khách |
| Medium | Chức năng phụ sai hoặc luồng ngoại lệ sai | Bộ lọc theo ngày ở màn báo cáo bỏ sót bản ghi cuối ngày |
| Low | Sai vặt, không ảnh hưởng nghiệp vụ | Chữ hiển thị sai chính tả, icon lệch 2px |
Thang này mỗi công ty một kiểu, có nơi dùng 5 mức, có nơi thêm mức Blocker riêng cho lỗi chặn cả đợt test. Cái quan trọng là cả team hiểu giống nhau và có ví dụ mẫu để đối chiếu, chứ không phải chọn được thang nào chuẩn hơn.
Ma trận severity và priority
Bốn ô, mỗi ô là một tình huống có thật:
| Priority cao | Priority thấp | |
|---|---|---|
| Severity cao | Cổng thanh toán trả về lỗi cho mọi giao dịch trên 5 triệu. Sập nghiệp vụ, sửa ngay đêm nay | Chức năng xuất báo cáo thuế bị crash, nhưng kỳ báo cáo còn 3 tháng nữa mới tới. Hỏng nặng, chưa gấp |
| Severity thấp | Tên công ty trên trang chủ viết sai chính tả trong ngày khai trương. Hỏng nhẹ, nhưng ai cũng nhìn thấy | Nhãn nút ở màn cấu hình nội bộ dùng sai thuật ngữ, mỗi tháng có 2 người dùng. Để đó, sửa sau |
Ô góc trên bên phải là chỗ hay bị tranh cãi nhất. QC thấy crash thì đặt Critical, PM nhìn lịch thì bảo để sprint sau. Cả hai đều đúng, vì họ đang nói về hai trục khác nhau. Có ma trận rồi thì cuộc họp ngắn hẳn.
Ví dụ thực tế
Chuỗi phòng gym. Thẻ hội viên quẹt ở cổng từ, và cái cổng đó là thứ duy nhất chặn người không đóng tiền đi vào. Đợt SIT ghi nhận 54 defect: 4 Critical, 11 High, 27 Medium, 12 Low.
Một trong 4 cái Critical: quẹt thẻ hai lần trong 3 giây thì hệ thống trừ hai lượt tập của gói đếm buổi. Không mất tiền, không sập hệ thống, nhưng lượt tập đã trừ sai thì không hoàn lại được từ bất kỳ màn hình nào — mất dữ liệu nghiệp vụ và không có đường đi vòng, đúng mô tả Critical ở bảng trên. Còn chi tiết mỗi ngày quầy lễ tân quẹt nhầm cỡ vài chục lần thì không đụng tới severity; nó là lý do để đẩy priority lên P1.
Cái đáng để ý: QC ngồi ở bàn thì đoán ra High, hỏi lễ tân một câu thì thành Critical. Severity đúng gần như luôn phải đi qua người làm nghiệp vụ.
Ai quyết định và sửa lại lúc nào
QC đặt lần đầu. Sau đó, trong buổi triage defect hằng ngày, BA và PM có thể điều chỉnh khi hiểu rõ hơn tác động nghiệp vụ. Việc điều chỉnh này bình thường, không phải là chê QC đánh giá sai.
Một quy ước nên có trong test plan: defect Critical thì báo ngay trong nhóm chat, không đợi tới buổi triage sáng hôm sau. Còn Low thì gom lại review một lượt mỗi tuần, đỡ ngắt quãng công việc mọi người.
Nếu đội bạn đang cãi nhau triền miên về severity, thử làm một trang ví dụ mẫu: liệt kê chừng 12 defect cũ đã có kết luận, ghi mức của từng cái. Người mới vào chỉ cần đối chiếu, không phải suy diễn từ định nghĩa trừu tượng.
