Vòng đời Trạng thái Báo cáo Lỗi
Một báo cáo lỗi thường đi qua những trạng thái nào từ lúc gửi tới lúc được xử lý xong, áp dụng được cho bất kỳ hệ quản lý issue nào.
Sau khi gửi, một báo cáo lỗi thường đi qua một chuỗi trạng thái cố định trước khi được xử lý xong. Mô hình dưới đây là mô hình tổng quát 2 tầng duyệt (nội bộ rồi tới bên yêu cầu/stakeholder) — nhiều nhóm chỉ dùng 1 tầng duyệt duy nhất, bạn có thể lược bớt tầng không áp dụng cho quy trình của mình.
1. Quy trình review
- Sau khi gửi, báo cáo có trạng thái Chờ duyệt (Awaiting Review). Người duyệt nội bộ (Reviewer/QA Lead) cần xem xét báo cáo.
- Nếu người duyệt cần thêm thông tin, trạng thái chuyển sang Yêu cầu bổ sung thông tin (Information Request). Bạn thường có một khoảng thời gian giới hạn (ví dụ 24 giờ) để chỉnh sửa và bổ sung.
- Sau khi bạn chỉnh sửa xong, trạng thái quay lại Chờ duyệt để người duyệt xem lại và ra quyết định.
- Nếu báo cáo không hợp lệ, thiếu tài liệu, hoặc bạn không phản hồi yêu cầu bổ sung đúng hạn, báo cáo chuyển sang Bị từ chối (Rejected). Nếu bạn cho rằng quyết định này chưa đúng, thường có cơ chế khiếu nại (dispute) để yêu cầu xem xét lại.
- Nếu được duyệt, trạng thái chuyển sang Đã chuyển cho bên yêu cầu (Forwarded), tới lượt bên yêu cầu/stakeholder xem xét.
- Bên yêu cầu cũng có thể gửi yêu cầu bổ sung thông tin riêng, trạng thái khi đó là Yêu cầu từ bên yêu cầu.
- Nếu bên yêu cầu chấp nhận, trạng thái chuyển thành Đã được chấp nhận (Accepted).
- Nếu bên yêu cầu từ chối, trạng thái chuyển thành Bị từ chối bởi bên yêu cầu (Rejected by requester).
Lưu ý: thường chỉ có thể tự xoá báo cáo của mình khi nó chưa được người duyệt nội bộ xem xét.
2. Ý nghĩa từng trạng thái
- Chờ duyệt: báo cáo vừa gửi, đang chờ người duyệt nội bộ xem xét.
- Yêu cầu bổ sung thông tin (nội bộ): người duyệt cần thêm thông tin, yêu cầu còn hiệu lực trong thời gian giới hạn.
- Đã chuyển cho bên yêu cầu: báo cáo đã qua vòng duyệt nội bộ, đang chờ bên yêu cầu xem xét.
- Bị từ chối (nội bộ): người duyệt từ chối kèm lý do cụ thể, có thể khiếu nại nếu không đồng ý.
- Yêu cầu bổ sung thông tin (từ bên yêu cầu): bên yêu cầu cần làm rõ thêm, cũng có thời hạn phản hồi.
- Đã được chấp nhận: bên yêu cầu đã xem xét và đồng ý đây là lỗi hợp lệ.
- Bị từ chối (bởi bên yêu cầu): bên yêu cầu không đồng ý đây là lỗi (nhưng quyết định duyệt trước đó của người duyệt nội bộ vẫn được ghi nhận).
- Lưu trữ (Archived): bên yêu cầu không chủ động chấp nhận hay từ chối trong thời gian quy định, hệ thống tự lưu trữ báo cáo lại.
Ví dụ trên GitHub Issues
Mô hình trên có thể ánh xạ bằng label: needs-triage → needs-info → triaged/accepted → wontfix/duplicate/closed. Một số dự án dùng thêm cột trên Project Board để thể hiện từng bước review.
3. “Được chấp nhận trước đây” không phải là bảo đảm
Một lỗi từng được chấp nhận trong quá khứ (dù bởi người duyệt nội bộ hay bên yêu cầu) không đảm bảo lỗi tương tự sẽ luôn được chấp nhận ở những lần báo cáo sau. Mục tiêu là đánh giá mọi lỗi theo cách nhất quán, nhưng không thể loại trừ khả năng một trường hợp trước đó đã bị bỏ sót, hoặc có thông tin mới phát sinh.
Một số tình huống khiến lỗi bị từ chối dù trước đó lỗi tương tự từng được chấp nhận:
- Người duyệt trước đây chấp nhận nhưng chưa chắc chắn, sau đó bên yêu cầu giải thích rằng đây thực chất là hành vi cố ý.
- Bên yêu cầu từng chấp nhận một lỗi nhưng không thêm vào danh sách lỗi đã biết, kèm ghi chú rằng yêu cầu sản phẩm đã thay đổi.
- Hướng dẫn của đợt test đã thay đổi (luôn đọc kỹ hướng dẫn mới nhất).
- Trước đó bạn từng được thưởng qua khiếu nại nhưng người xử lý khiếu nại đã yêu cầu không tiếp tục báo loại lỗi đó nữa.
- Có ai đó trong nhóm phụ trách yêu cầu bạn ngừng báo thêm loại lỗi này qua kênh trao đổi.
- Quy định chung của hệ thống đã thay đổi.