Defect Life Cycle
Chuỗi trạng thái mà một defect đi qua từ lúc được phát hiện tới lúc đóng: New, Assigned, Open, Fixed, Retest, Verified, Closed, cộng các nhánh rẽ như Reopen, Rejected hay Deferred.
Định nghĩa
Một defect hiếm khi chỉ có hai trạng thái mở và đóng. Nó đi qua nhiều tay: QC phát hiện, lead phân công, dev sửa, QC kiểm lại, ai đó xác nhận đóng. Mỗi lần chuyển tay là một trạng thái, và cái quy trình đó tồn tại để không ai phải hỏi "cái lỗi hôm qua giờ đến đâu rồi".
Vòng đời defect là cách theo dõi trách nhiệm: nhìn trạng thái là biết quả bóng đang ở chân ai.
Các trạng thái trong Jira
Luồng thuận, gặp ở hầu hết dự án:
- New — QC vừa log, chưa ai xem.
- Assigned — lead hoặc PM gán cho một dev cụ thể.
- Open (hoặc In Progress) — dev đã nhận và đang sửa.
- Fixed — dev báo sửa xong, chờ build mới.
- Retest — QC nhận build và đang kiểm lại.
- Verified — QC xác nhận đã hết lỗi.
- Closed — đóng chính thức, thường sau khi lên môi trường tiếp theo.
Các nhánh rẽ:
- Reopen — retest vẫn còn lỗi, quay lại tay dev.
- Rejected — dev cho rằng đây không phải lỗi.
- Deferred — công nhận là lỗi nhưng để phiên bản sau.
- Duplicate — trùng với một ticket đã có.
- Cannot Reproduce — dev không tái hiện được.
Nhìn trạng thái để biết ai đang phải hành động:
| Trạng thái | Bóng đang ở chân ai | Việc kế tiếp |
|---|---|---|
| New | Lead hoặc PM | Phân loại, gán người |
| Open | Dev | Sửa và ghi lại nguyên nhân |
| Fixed | Người dựng build | Đưa bản mới lên môi trường test |
| Retest | QC | Kiểm lại, kết luận Verified hay Reopen |
| Rejected | QC, rồi tới BA | Đưa bằng chứng hoặc nhờ phân xử |
Tên trạng thái mỗi công ty đặt một kiểu, có nơi gộp Fixed với Ready for Test, có nơi bỏ hẳn Verified. Chuẩn hóa trong nội bộ dự án là đủ, đừng mất buổi họp để cãi tên gọi.
Rejected và Cannot Reproduce — hai chỗ hay xảy ra chiến tranh
Đây là phần thật của nghề. Dev đóng ticket với lý do "spec không có, đây là yêu cầu mới". QC mở lại vì cho rằng hệ thống chạy vô lý. Ping pong ba vòng, ai cũng khó chịu, ticket đứng yên năm ngày.
Với Rejected, nguyên nhân gần như luôn là tài liệu. Cách gỡ: QC dán trích dẫn cụ thể từ FRD hoặc acceptance criteria vào ticket. Nếu không trích được, gọi BA vào phân xử. BA đọc lại tài liệu và kết luận một trong hai hướng — spec có mà làm sai thì dev sửa; spec thiếu thì thừa nhận và quyết định fix ngay hay mở CR. Không có hướng thứ ba là để nguyên đó.
Với Cannot Reproduce, hay là do khác môi trường, khác dữ liệu, khác thời điểm. Yêu cầu bổ sung: build number, thời điểm chính xác, tài khoản, mã giao dịch, video. Nhiều lỗi chỉ xuất hiện với dữ liệu cũ trên UAT mà môi trường DEV không có. Đừng đóng ticket khi chưa ai xem log của đúng khung giờ đó.
Một quy ước nhỏ mà hiệu quả: dev muốn chuyển sang Rejected hoặc Cannot Reproduce thì phải viết ít nhất hai dòng lý do và gán lại cho QC, không được tự đóng luôn.
Ví dụ thực tế
Sáu ticket bị dev đóng với trạng thái Rejected trong đúng một sprint, trên tổng số 31 defect. Dự án là ví nội bộ cho một khu công nghiệp, khoảng 7.400 người dùng. Rà lại từng cái trong sáu: 2 cái đúng là QC hiểu nhầm, 1 cái trùng, còn 3 cái là tài liệu không mô tả trường hợp thẻ hết hạn giữa lúc đang giao dịch.
Ba cái đó nếu cứ để dev và QC tự xử thì còn cãi tới cuối sprint. BA vào, đọc lại tài liệu 15 phút, xác nhận thiếu, viết bổ sung quy tắc, đổi cả ba sang trạng thái Open kèm mô tả mới. Xong trong buổi chiều.
Vai trò trọng tài của BA
Bạn không cần theo dõi từng ticket. Nhưng mỗi ngày lọc hai bộ lọc trong Jira là đủ: các defect đang Rejected và các defect đang Cannot Reproduce. Đó là chỗ tồn đọng âm thầm, không ai báo cáo, rồi bất ngờ nổ ra vào tuần cuối trước go-live.
Khi phân xử, tránh dùng chữ "ai sai". Nói theo hướng hệ thống nên hành xử thế nào và căn cứ nằm ở đâu. Dev nghe "chỗ này tài liệu thiếu, mình bổ sung" thì gật. Nghe "em làm sai rồi" thì mở miệng cãi, dù kết luận y hệt.
