Triển khai dự án
Ưu tiên lỗi theo tác động và khả năng tái hiện
Ưu tiên lỗi cần xét hậu quả với người dùng, phạm vi ảnh hưởng và cách phục hồi mà không bỏ qua chất lượng bằng chứng. Tách tác động khỏi khả năng tái hiện để lỗi nghiêm trọng không thường xuyên vẫn được điều tra.
Lỗi dễ trình diễn chưa chắc là lỗi quan trọng nhất cần sửa. Một thất bại hiếm gặp có thể ngắt tác vụ trọng yếu, còn lỗi hình thức liên tục có thể dễ tránh. Phân loại lỗi cần hai đánh giá riêng: người dùng chịu điều gì và nhóm hiểu hiện tượng chắc tới đâu. Gộp chúng vào nhãn mức độ nghiêm trọng mơ hồ có thể che cả tính khẩn cấp lẫn điều chưa biết.
Mô tả tác động trước khi chọn nhãn
Xác định tác vụ, người dùng tiếp xúc với lỗi và hậu quả khi thất bại. Hỏi công việc có tiếp tục được không, dữ liệu có cần sửa không và có cách xử lý tạm an toàn không. Ghi riêng phạm vi quan sát được và ước lượng. Không biến một báo cáo thành khẳng định mọi người dùng đều bị ảnh hưởng.
Dùng định nghĩa mức độ nghiêm trọng của tổ chức để mô tả hậu quả, rồi xác định ưu tiên như thứ tự làm việc. Lỗi ít gặp vẫn có thể cần điều tra ngay nếu hậu quả tiềm tàng nghiêm trọng. Lỗi hình thức phổ biến có thể chờ nếu nhóm giải thích được đánh đổi. Đây là quy tắc khuyến nghị, không phải hệ phân loại phổ quát.
Làm bằng chứng tái hiện được khi có thể
Hướng dẫn viết báo cáo lỗi của Mozilla yêu cầu bước tái hiện rõ và tách quan sát thực tế khỏi suy đoán.[5] Áp dụng cách đó cho phiên bản thử, trạng thái ban đầu, thao tác chính xác, kết quả mong đợi và kết quả thực tế. Chỉ đính kèm nhật ký và ví dụ đã xử lý phù hợp để không lộ dữ liệu nhạy cảm.
Dùng danh sách sau trước khi phân công bước tiếp theo.
- Nêu tác vụ bị chặn và hậu quả quan sát được với người dùng.
- Ghi phạm vi đã biết và điều chưa chắc về ảnh hưởng rộng hơn.
- Lưu phiên bản, môi trường, trạng thái đầu và các lần thử tái hiện.
- Đánh giá mức an toàn cùng công sức của cách xử lý tạm.
- Phân công sửa, điều tra hoặc trì hoãn có theo dõi cho người cụ thể.
Ví dụ giả định: yêu cầu lấy hàng bị trùng
Trong ví dụ giả định về hệ thống đặt lịch thu gom, người dùng báo có hai yêu cầu lấy hàng sau khi gửi lại vì phản hồi chậm. Nhóm chưa tái hiện ổn định. Một lỗi căn chỉnh khác luôn xuất hiện ở trang xác nhận. Sửa căn chỉnh trước chỉ vì dễ tái hiện sẽ đánh đồng chất lượng bằng chứng với tác động tới người dùng.
Người phân loại giao điều tra yêu cầu trùng và nhờ hỗ trợ lưu ví dụ đã loại thông tin nhạy cảm, kèm phiên bản cùng chuỗi thao tác. Nhóm kiểm tra xem vận hành có phát hiện yêu cầu trùng trước khi điều xe không. Lỗi hiển thị vẫn được ghi nhận, nhưng ưu tiên phản ánh hậu quả ít gây gián đoạn hơn.
Xem lại ưu tiên khi bằng chứng thay đổi
Điều tra cần làm rõ điều kiện gây lỗi, đưa ra cách hạn chế ảnh hưởng hoặc nêu phần vẫn chưa biết. Đặt ngưỡng xem lại thay vì để “không tái hiện được” thành điểm dừng vĩnh viễn. Báo cáo lặp lại, cách xử lý tạm thất bại hoặc phạm vi mới phải mở lại quyết định.
Phân loại cũng tốn thời gian, còn chấm điểm cầu kỳ có thể tạo cảm giác chính xác giả. Giữ phân nhóm dễ hiểu và ghi lý do cho quyết định quan trọng. Trong trao đổi bàn giao tiếp theo, xem lỗi chưa giải quyết có tác động lớn nhất. Hỏi bằng chứng hiện tại ủng hộ sửa, điều tra thêm hay chủ động chấp nhận chờ, rồi nêu người sở hữu lựa chọn đó.