Bug report là gì? Cách viết báo cáo lỗi và phân biệt Severity với Priority
Tìm ra bug mới là nửa công việc. Nửa còn lại là mô tả nó đủ tốt để người khác tái hiện được mà không phải hỏi lại bạn câu nào. Một bug report kém thường kết thúc bằng trạng thái "Cannot reproduce" — và con lỗi đó vẫn nằm nguyên trong sản phẩm.
Bug report là gì?
Bug report (báo cáo lỗi, defect report) là tài liệu ghi nhận một khiếm khuyết được phát hiện trong phần mềm, mô tả đủ thông tin để người khác tái hiện, đánh giá mức độ ảnh hưởng và sửa chữa nó.
Hãy nghĩ về bug report như một lời đề nghị: bạn đang xin thời gian của lập trình viên. Report càng rõ, chi phí để họ bắt đầu càng thấp, và khả năng lỗi được sửa sớm càng cao.
Các thành phần của một bug report
| Thành phần | Vì sao cần | Ví dụ |
|---|---|---|
| Tiêu đề | Đọc là hiểu ngay lỗi gì, ở đâu — quyết định report có được mở ra đọc hay không | [Checkout] Tổng tiền không cập nhật khi xoá sản phẩm cuối cùng khỏi giỏ hàng |
| Môi trường | Lỗi thường chỉ xảy ra trên một cấu hình nhất định | Chrome 141, Windows 11, môi trường Staging, build 2.14.3 |
| Precondition | Trạng thái cần có trước khi tái hiện | Đã đăng nhập, giỏ hàng có đúng 1 sản phẩm |
| Các bước tái hiện | Phần quan trọng nhất — đánh số, mỗi bước một hành động | 1. Mở /cart 2. Bấm icon xoá trên sản phẩm duy nhất 3. Quan sát vùng Tổng tiền |
| Kết quả thực tế | Điều bạn thực sự nhìn thấy | Tổng tiền vẫn hiển thị 450.000đ dù giỏ hàng đã trống |
| Kết quả mong đợi | Điều đáng lẽ phải xảy ra, kèm căn cứ | Tổng tiền hiển thị 0đ và hiện trạng thái giỏ hàng trống (REQ-CART-008) |
| Bằng chứng | Ảnh chụp màn hình, video, log, response API | Ảnh chụp kèm tab Network cho thấy API trả về total = 450000 |
| Severity | Mức ảnh hưởng kỹ thuật | Major |
| Priority | Mức khẩn cấp cần sửa | High |
| Tần suất | Lỗi xảy ra luôn hay thỉnh thoảng | 5/5 lần thử |
Phân biệt Severity và Priority
Đây là cặp khái niệm bị nhầm nhiều nhất, và cũng gần như chắc chắn xuất hiện trong đề thi ISTQB. Cách nhớ đơn giản: Severity là "hỏng nặng đến đâu", Priority là "sửa gấp đến mức nào".
| Tiêu chí | Severity (Mức nghiêm trọng) | Priority (Độ ưu tiên) |
|---|---|---|
| Trả lời câu hỏi | Lỗi ảnh hưởng tới hệ thống nặng đến đâu? | Cần sửa gấp đến mức nào? |
| Góc nhìn | Kỹ thuật | Nghiệp vụ, khách hàng, thị trường |
| Ai quyết định | Tester | Quản lý sản phẩm, test lead, khách hàng |
| Thang đo thường dùng | Critical / Major / Moderate / Minor | Urgent / High / Medium / Low |
Bốn tổ hợp và ví dụ thực tế
| Tổ hợp | Ví dụ | Vì sao |
|---|---|---|
| Severity cao — Priority cao | Không thanh toán được đơn hàng trên môi trường production | Hỏng chức năng cốt lõi và đang mất doanh thu từng phút |
| Severity cao — Priority thấp | Ứng dụng sập khi đổi ngôn ngữ sang tiếng Nhật, nhưng thị trường Nhật chưa mở | Về kỹ thuật rất nặng, nhưng chưa ai dùng tới nên chưa gấp |
| Severity thấp — Priority cao | Logo công ty bị sai chính tả trên trang chủ | Không ảnh hưởng chức năng, nhưng ảnh hưởng hình ảnh thương hiệu ngay lập tức |
| Severity thấp — Priority thấp | Khoảng cách giữa hai nút lệch 2 pixel ở trang cài đặt nâng cao | Không ảnh hưởng chức năng, ít người nhìn thấy |
Vòng đời của một bug
Tên trạng thái khác nhau giữa các công cụ, nhưng luồng chung thì giống nhau ở hầu hết dự án.
- New — tester vừa tạo báo cáo lỗi.
- Assigned — lỗi được giao cho một lập trình viên xử lý.
- Open / In Progress — lập trình viên đang phân tích và sửa.
- Fixed — đã sửa xong, chờ kiểm tra lại.
- Retest — tester xác nhận lại trên bản build mới.
- Closed — xác nhận đã sửa đúng, đóng lỗi.
- Reopened — nếu retest vẫn thấy lỗi, mở lại và ghi rõ bản build nào vẫn còn.
Các trạng thái từ chối và cách xử lý
| Trạng thái | Nghĩa là | Tester nên làm gì |
|---|---|---|
| Rejected / Not a bug | Lập trình viên cho rằng đây là hành vi đúng | Đối chiếu lại tài liệu yêu cầu; nếu tài liệu mơ hồ thì đưa BA vào cuộc |
| Duplicate | Đã có report khác về cùng lỗi này | Kiểm tra xem có thật sự trùng không, hay chỉ giống triệu chứng nhưng khác nguyên nhân |
| Cannot reproduce | Không tái hiện được theo mô tả | Bổ sung video, log, dữ liệu chính xác và thông tin môi trường |
| Deferred | Thừa nhận là lỗi nhưng hoãn sang phiên bản sau | Ghi nhận rủi ro, đảm bảo quyết định hoãn được ghi lại rõ ràng |
Mẫu bug report dùng ngay
Tiêu đề: [Giỏ hàng] Tổng tiền không về 0 khi xoá sản phẩm cuối cùng
Môi trường: Staging | build 2.14.3 | Chrome 141 | Windows 11
Tài khoản: buyer_test_02 (đã đăng nhập)
Tần suất: 5/5 lần
Precondition:
- Giỏ hàng có đúng 1 sản phẩm, giá 450.000đ
Các bước tái hiện:
1. Mở trang /cart
2. Bấm biểu tượng thùng rác trên sản phẩm duy nhất
3. Quan sát vùng "Tổng tiền" ở cột bên phải
Kết quả thực tế:
- Danh sách sản phẩm trống, nhưng "Tổng tiền" vẫn hiển thị 450.000đ
- API GET /api/cart/summary trả về { "items": [], "total": 450000 }
Kết quả mong đợi:
- "Tổng tiền" hiển thị 0đ và hiện trạng thái giỏ hàng trống (theo REQ-CART-008)
Bằng chứng: cart-total-bug.mp4, screenshot-network-tab.png
Severity: Major | Priority: HighCâu hỏi thường gặp
Severity và Priority khác nhau thế nào?
Severity đo mức độ nghiêm trọng về mặt kỹ thuật của lỗi và thường do tester quyết định. Priority đo mức độ khẩn cấp cần sửa dựa trên yếu tố nghiệp vụ, thường do quản lý sản phẩm hoặc khách hàng quyết định. Một lỗi có thể nghiêm trọng nhưng không gấp, hoặc nhẹ nhưng phải sửa ngay.
Vì sao bug của tôi bị đóng với trạng thái Cannot reproduce?
Thường do thiếu thông tin về môi trường, dữ liệu, quyền tài khoản hoặc thứ tự thao tác. Cách xử lý là tái hiện lại từ trạng thái sạch, quay video toàn bộ quá trình, ghi rõ số hiệu build và đính kèm log hoặc response API để chứng minh lỗi có thật.
Có nên gộp nhiều lỗi vào một bug report không?
Không nên. Mỗi bug report chỉ nên mô tả một khiếm khuyết, vì mỗi lỗi có thể được giao cho người khác nhau, sửa ở thời điểm khác nhau và có mức ưu tiên khác nhau. Gộp lại khiến việc theo dõi trạng thái sửa trở nên bất khả thi.
Tester có quyền quyết định Priority không?
Tester thường đề xuất Priority, nhưng quyết định cuối cùng thuộc về quản lý sản phẩm, test lead hoặc khách hàng, vì nó phụ thuộc vào yếu tố kinh doanh nằm ngoài phạm vi kỹ thuật. Severity thì tester đánh giá và chịu trách nhiệm chính.