Bug Report chuẩn cho Fresher: Cách mô tả, severity và bước tái hiện để dev hiểu ngay
7 giờ tới · 9 phút đọc
Mình từng nộp bug report bị dev trả về ngay lập tức
Hồi mới vào nghề, mình log một bug kiểu này: "Button không hoạt động". Dev đọc xong hỏi ngược lại: "Button nào? Trên màn hình nào? Làm gì thì không hoạt động?". Mất thêm 30 phút giải thích qua lại, cuối cùng dev mới reproduce được.
Bug report tệ không chỉ làm mất thời gian của cả hai bên. Nó còn khiến bug bị để lại, vì dev không biết bắt đầu từ đâu để fix. Tệ hơn nữa - với fresher, một bug report mơ hồ dễ bị gắn nhãn "thiếu chuyên nghiệp" ngay từ sprint đầu tiên.
Bài này mình viết để bạn không mắc những lỗi đó. Học đúng từ đầu, tiết kiệm rất nhiều lần bị dev "chê".
Bug report rõ ràng giúp dev fix đúng lần đầu, không cần hỏi lại
Cấu trúc một bug report đầy đủ gồm những gì?
Một bug report chuẩn có 7 phần. Thiếu bất kỳ phần nào, dev sẽ phải hỏi lại - và bạn sẽ mất thêm một vòng ping-pong không đáng.
1. Title (tiêu đề) - Câu đầu tiên dev đọc. Phải nói được: cái gì bị lỗi, ở đâu, xảy ra khi nào.
- Tệ:
Button không hoạt động - Tốt:
[Web] Nút "Thêm vào giỏ hàng" không phản hồi khi sản phẩm đã hết hàng
2. Description (mô tả) - Tóm tắt lỗi bằng 2-3 câu. Không copy lại title, mà bổ sung context: Lỗi này ảnh hưởng tính năng nào? Có xảy ra liên tục không?
3. Steps to reproduce (bước tái hiện) - Phần quan trọng nhất. Mình sẽ nói kỹ hơn ở mục sau.
4. Expected result (kết quả mong đợi) - Hệ thống nên làm gì? Ví dụ: Hiển thị thông báo "Sản phẩm đã hết hàng" và disable nút mua.
5. Actual result (kết quả thực tế) - Hệ thống thực sự làm gì? Ví dụ: Nút vẫn bấm được, nhưng không có gì xảy ra - không thêm vào giỏ, không báo lỗi.
6. Severity và Priority - Mức độ nghiêm trọng và độ ưu tiên. Mình giải thích chi tiết ở phần tiếp.
7. Attachment (file đính kèm) - Screenshot, video, log file. Thiếu phần này dev rất khó hình dung lỗi trông như thế nào.
7 phần này thiếu bất kỳ phần nào cũng làm chậm quá trình fix bug
Một điều nhiều fresher hay nhầm: Expected result không phải là "không bị lỗi". Phải mô tả hành vi cụ thể bạn mong đợi dựa trên spec hoặc logic thông thường. Dev cần biết đích đến là gì để code đúng hướng.
Severity và Priority: hai khái niệm dễ nhầm nhất
Nhiều fresher dùng lẫn lộn hai cái này. Đây là cách phân biệt nhanh:
- Severity (mức độ nghiêm trọng) - Bug ảnh hưởng nặng đến hệ thống đến đâu? Do tester đánh giá dựa trên kỹ thuật.
- Priority (độ ưu tiên) - Bug cần fix sớm đến đâu? Do PM/lead quyết định dựa trên business.
Ví dụ thực tế: Logo bị hiển thị sai màu trên trang chủ. Severity = Low (không ảnh hưởng chức năng). Nhưng Priority = High vì ngày mai là sự kiện ra mắt sản phẩm. Ngược lại, một bug crash app khi nhập ký tự đặc biệt vào ô tìm kiếm có Severity = Critical, nhưng Priority = Medium nếu tính năng tìm kiếm vừa được cắt khỏi sprint này.
Severity do tester đánh giá kỹ thuật, Priority do team quyết định theo business
4 mức Severity bạn cần biết
| Mức | Ý nghĩa | Ví dụ |
|---|---|---|
| Critical | App crash, mất dữ liệu, không dùng được | Đăng nhập xong app tự thoát |
| High | Tính năng chính bị lỗi, có workaround | Thanh toán không gửi được email xác nhận |
| Medium | Tính năng phụ bị lỗi hoặc UI sai | Filter sản phẩm không sort đúng thứ tự |
| Low | Lỗi nhỏ, không ảnh hưởng UX nhiều | Lỗi chính tả trong tooltip |
Khi mới bắt đầu, bạn sẽ hay chọn severity cao hơn thực tế - kiểu gì cũng gắn Critical cho an toàn. Mình hiểu tâm lý đó. Nhưng "wolf cry" nhiều quá, dev sẽ bắt đầu bỏ qua bug của bạn. Hãy đánh giá thật sự dựa trên: "Nếu bug này không fix, user bị ảnh hưởng nặng đến đâu?"
Steps to reproduce: phần quan trọng nhất bug report
Nếu dev không reproduce được bug, bug đó coi như không tồn tại. Họ sẽ đổi trạng thái sang "Cannot Reproduce" và bạn lại phải viết lại từ đầu.
Một bộ steps tốt phải đủ để người chưa biết gì về bug đó cũng làm theo và thấy lỗi. Nguyên tắc viết:
- Mỗi bước = một hành động duy nhất. Không gộp nhiều hành động vào một dòng.
- Bắt đầu từ trạng thái ban đầu - user đang ở đâu, đã login chưa, dùng browser/device gì.
- Cụ thể hóa dữ liệu test - nhập chính xác cái gì. Đừng viết "nhập thông tin" - viết
Nhập email: [email protected], password: Test@123. - Kết thúc bằng hành động trigger bug - bước cuối cùng gây ra lỗi.
Steps càng cụ thể, xác suất dev reproduce được càng cao
Ví dụ thực tế - Bug trên trang đăng ký Shopee:
Môi trường: Chrome 124, Windows 11, màn hình 1920x1080
Account test: Chưa đăng nhập
Steps to Reproduce:
1. Truy cập https://shopee.vn
2. Click nút "Đăng ký" góc trên phải
3. Nhập số điện thoại: 0901234567
4. Click "Tiếp theo"
5. Nhập mã OTP: 123456 (mã test)
6. Click "Xác nhận"
7. Tại form tạo mật khẩu, nhập: Abc@123!#$%^&*()
8. Click "Hoàn tất đăng ký"
Expected: Tài khoản được tạo thành công, chuyển về trang chủ
Actual: Trang báo lỗi "Mật khẩu không hợp lệ" dù đáp ứng đủ yêu cầu hiển thị
Thấy sự khác biệt không? Với steps này, dev chỉ cần làm theo từng dòng là reproduce được ngay - không cần hỏi thêm gì.
Một lưu ý nữa: Ghi rõ môi trường test (browser, OS, version app). Cùng một bug có thể chỉ xảy ra trên Chrome chứ không xảy ra trên Safari. Nếu không ghi, dev test trên Safari không thấy, lại mark "Cannot Reproduce".
Attachment: đừng để dev "đoán" lỗi trông như thế nào
Screenshot mờ, crop sai chỗ, hoặc thiếu hẳn attachment là lý do số hai khiến bug report bị trả về (sau thiếu steps).
Quy tắc attachment mình hay nhắc fresher:
- Screenshot phải thấy full màn hình hoặc ít nhất thấy URL + vùng bị lỗi. Đừng crop sát vào lỗi đến mức không biết đang ở trang nào.
- Đánh dấu vùng bị lỗi bằng mũi tên đỏ hoặc khoanh đỏ - dùng Snagit, ShareX, hoặc đơn giản là Paint.
- Video nếu lỗi khó chụp - lỗi animation, lỗi load, lỗi timeout nên quay video ngắn 15-30 giây thay vì screenshot.
- Console log nếu là lỗi kỹ thuật - Bấm F12, tab Console, chụp lại error message. Dev sẽ cảm ơn bạn vì điều này.
Attach cả console log khi có lỗi kỹ thuật - dev sẽ fix nhanh hơn nhiều
Tool screenshot mình hay dùng: ShareX (free, có thể record màn hình, annotate ngay trong app). Nếu bạn dùng Mac thì CleanShot X hoặc built-in screenshot của Mac cũng ổn.
Một lỗi hay gặp với fresher: chụp screenshot rồi paste thẳng vào Jira mà không đặt tên file. Sau 2 tuần cả team không biết Screenshot_20241203_143022.png là bug gì. Đặt tên có ý nghĩa: login-special-char-bug.png hoặc cart-button-disabled-state.png.
Template bug report và checklist trước khi submit
Dưới đây là template mình dùng cho cả Jira lẫn Excel. Copy về dùng luôn, chỉnh tên project và môi trường cho phù hợp.
Tải template tại đây: Tải template Bug Report (Excel)
## BUG REPORT TEMPLATE
**Title:** [Platform] Mô tả ngắn: cái gì bị lỗi + khi nào xảy ra
**Environment:**
- OS: [Windows 11 / macOS 14 / Android 13 / iOS 17]
- Browser/App version: [Chrome 124 / App v2.3.1]
- Account type: [Guest / User / Admin]
**Description:**
[2-3 câu tóm tắt lỗi, ảnh hưởng tính năng nào]
**Steps to Reproduce:**
1. [Bước 1]
2. [Bước 2]
3. [...]
**Expected Result:**
[Hệ thống nên làm gì]
**Actual Result:**
[Hệ thống thực sự làm gì]
**Severity:** [Critical / High / Medium / Low]
**Priority:** [High / Medium / Low]
**Attachment:**
[Link screenshot / video]
Checklist nhanh trước khi bấm Submit
Checklist 5 điểm trước khi submit
- [ ] Title có đủ: cái gì - ở đâu - khi nào?
- [ ] Steps to reproduce đủ để người khác làm theo không cần hỏi?
- [ ] Expected vs Actual result khác nhau và mô tả cụ thể?
- [ ] Severity chọn đúng - không phải Critical cho tất cả?
- [ ] Có ít nhất 1 screenshot/video đính kèm?
Nếu 5 cái này đều tick, bug report của bạn đã đủ chuẩn để submit. Mình đảm bảo dev sẽ ít hỏi lại hơn nhiều.