“Bắn bug” không chỉ là chụp màn hình rồi giao ticket cho developer. Một defect report tốt phải giúp người nhận hiểu vấn đề, tái hiện được failure, đánh giá ảnh hưởng và theo dõi từ lúc phát hiện đến khi đóng.
Trước khi report bug
- Thử tái hiện để xác nhận vấn đề không phải thao tác nhầm hoặc lỗi tạm thời.
- Kiểm tra đúng build, environment, configuration, account và test data.
- So sánh actual result với requirement hoặc expected behavior.
- Tìm ticket tương tự để tránh duplicate.
- Thu thập screenshot, video, log, request/response và database evidence cần thiết.
- Thu gọn steps và dữ liệu để xác định điều kiện tối thiểu gây failure.
Tốt hơn: “Đơn hàng bị tạo hai lần khi người dùng bấm nút Thanh toán hai lần trong lúc API phản hồi chậm”. Tiêu đề cho biết chức năng, điều kiện và failure.
Cấu trúc một Bug Report
- ID duy nhất và tiêu đề ngắn gọn. (ID thường do phần mềm tự gen ra)
- Người report, thời điểm phát hiện
- Thông tin đi kèm: Environment, build/version, browser/device và configuration liên quan.
- Preconditions và test data: Tiền điều kiện và dữ liệu test
- Steps to reproduce (các bước thực hiện) rõ ràng, đánh số thứ tự
- Expected result và Actual result. (Kì vọng và biểu hiện thực tế của bug)
- Evidence: screenshot, video, log, request/response.
- Severity, Priority, Status và người phụ trách.
- Liên kết requirement, test case và ticket liên quan.
Severity và Priority khác nhau thế nào?
| Tiêu chí | Severity | Priority |
|---|---|---|
| Ý nghĩa | Mức độ ảnh hưởng của defect | Mức độ cần sửa sớm |
| Câu hỏi | Hỏng nghiêm trọng đến đâu? | Khi nào phải xử lý? |
| Căn cứ | Ảnh hưởng tới user, dữ liệu, an toàn và requirement | Business value, deadline, số user, workaround và risk |
| Ai quyết định | Tester thường đề xuất | PO/PM/triage team thường quyết định cùng kỹ thuật |
Low Severity nhưng High Priority: logo đối tác bị sai ngay trên trang chủ trước buổi ra mắt lớn. Không nghiêm trọng với người dùng nhưng là cái phải fix sớm
Vòng đời Defect phổ biến
Mỗi công ty có workflow khác nhau, nhưng một luồng điển hình là:
- New/Open: tester tạo ticket.
- Triage/Analyzed: team xác nhận, phân loại, đặt severity/priority và quyết định hướng xử lý.
- Assigned/In Progress: người phụ trách phân tích và sửa.
- Fixed/Ready for QA: bản sửa đã có trên build phù hợp.
- Retest/Awaiting Confirmation: tester kiểm tra bản sửa.
- Closed: failure cũ không còn và điều kiện đóng được đáp ứng.
- Reopened: lỗi vẫn tồn tại, tái xuất hiện hoặc fix chưa đúng.
Các nhánh khác có thể gồm
Rejected/Not a bug: Bug bị bắn sai, không phải bug
Duplicate: Bug bị trùng
Cannot reproduce: Bug không tái hiện được
Won’t fix: Đúng là có bug nhưng PO quyết định sẽ không fix
Retest và Regression sau khi fix
Retest/Confirmation Testing xác nhận defect ban đầu đã được sửa. Tester chạy lại steps từng gây failure và các test liên quan trực tiếp đến bản fix.
Regression Testing kiểm tra thay đổi có gây hậu quả bất lợi ở nơi khác hay không. Phạm vi nên dựa trên impact analysis, không phải lúc nào cũng chạy toàn bộ hệ thống.
Kết luận
Bug report tốt rút ngắn thời gian tái hiện, giảm tranh luận và tạo dữ liệu cho quản lý chất lượng. Mục tiêu không phải đếm xem tester “bắn” được bao nhiêu bug, mà là giúp team hiểu, ưu tiên và xử lý đúng rủi ro của sản phẩm.
