TestingMột report dùng được phải trả lời đủ bốn câu: làm gì, mong đợi gì, thực tế ra sao, ở đâu.
- Tiêu đề: một dòng nêu triệu chứng + ngữ cảnh. "Đặt hàng lỗi" thì vô dụng; "Checkout trả 500 khi mã giảm giá đã hết hạn" thì dev khoanh vùng được ngay.
- Các bước tái hiện: đánh số, bắt đầu từ trạng thái xác định (tài khoản nào, dữ liệu nào), mỗi bước một hành động. Ghi rõ tần suất: luôn luôn, hay 1/10 lần.
- Kỳ vọng vs thực tế: hai dòng tách bạch. Đây là chỗ phân biệt bug thật với hiểu nhầm yêu cầu.
- Môi trường: dev/staging/prod, phiên bản build hoặc commit, trình duyệt/OS, thời điểm xảy ra.
- Bằng chứng: ảnh chụp, đoạn log,
traceId/requestId, payload request.traceIdlà thứ tiết kiệm thời gian nhất — dev tra thẳng log ra đúng lần gọi.
Hai lỗi hay gặp: gộp nhiều bug vào một ticket (không đóng riêng được, không ưu tiên riêng được), và viết suy đoán nguyên nhân thay vì hiện tượng ("do cache sai") khiến dev đi nhầm hướng. Mô tả cái quan sát được, phần chẩn đoán để riêng.