Viết bug report để dev sửa ngay: mẫu 8 trường, mức độ nghiêm trọng và 10 lỗi hay gặp
Một bug được tìm ra mới đi được nửa đường. Nửa còn lại là dev hiểu đúng, tái hiện được và sửa. Bug report viết kém dẫn đến "Cannot reproduce", hỏi qua hỏi lại trên Slack, hoặc bug nằm trong backlog hàng tháng. Bài này tổng hợp cách viết bug report mà mình thấy hiệu quả nhất, kèm mẫu dùng ngay.
1. Mẫu 8 trường
| Trường | Viết gì | Ví dụ |
|---|---|---|
| Tiêu đề | [Màn hình] Hành động + kết quả sai | [Đăng ký] Nhập SĐT +84 báo "Số không hợp lệ" |
| Môi trường | Bản build, môi trường, trình duyệt/thiết bị | staging v2.3.1, Chrome 130, Windows 11 |
| Điều kiện trước | Tài khoản, dữ liệu, cấu hình cần có | Tài khoản chưa đăng nhập |
| Các bước | Đánh số, mỗi bước một hành động | 1. Mở /dang-ky 2. Nhập SĐT +84912345678 3. Bấm Đăng ký |
| Kết quả thực tế | Đúng những gì thấy, kèm nguyên văn thông báo | Hiện "Số điện thoại không hợp lệ" |
| Kết quả mong đợi | Theo đặc tả, ghi nguồn | Chấp nhận, lưu thành 0912345678 (đặc tả mục 3.2) |
| Bằng chứng | Ảnh, video, log console, request/response | video 12s, HAR file |
| Mức độ / Ưu tiên | Severity và Priority (xem phần 3) | Major / P2 |
Tiêu đề quan trọng hơn bạn nghĩ: người lead lướt danh sách 50 bug chỉ đọc tiêu đề. Tiêu đề tốt trả lời được "ở đâu, làm gì, sai thế nào" mà không cần mở ra.
2. Viết các bước tái hiện
- Bắt đầu từ trạng thái sạch. "Đăng nhập bằng tài khoản mới tạo" thay vì "vào trang hồ sơ" (tài khoản cũ của bạn có thể có dữ liệu đặc biệt).
- Ghi dữ liệu cụ thể. "Nhập tên
Nguyễn Thị Ngọc Ánh" chứ không phải "nhập tên có dấu". - Mỗi bước một hành động, dùng đúng chữ trên giao diện: Bấm "Lưu thay đổi".
- Tự chạy lại các bước một lần trước khi gửi. Nếu chỉ xảy ra thỉnh thoảng, ghi rõ tần suất: "3/10 lần".
- Thu hẹp phạm vi. Thử thêm một trình duyệt, một tài khoản khác. "Chỉ lỗi trên Safari iOS" giúp dev tiết kiệm cả buổi.
3. Severity khác Priority
- Severity (mức độ nghiêm trọng): ảnh hưởng kỹ thuật của bug. Tester đánh giá.
- Priority (ưu tiên): cần sửa gấp đến đâu. PO/lead quyết định, dựa trên kinh doanh.
| Severity | Khi nào | Ví dụ |
|---|---|---|
| Blocker | Chặn luồng chính, không có cách khác | Không thanh toán được |
| Critical | Mất dữ liệu, sai tiền, lỗi bảo mật | Trừ tiền 2 lần |
| Major | Chức năng sai nhưng có cách vòng | Lọc theo ngày trả kết quả sai |
| Minor | Ảnh hưởng nhỏ | Sai thông báo lỗi |
| Trivial | Thẩm mỹ | Lệch 2px, sai chính tả |
Ví dụ kinh điển: logo sai màu trên trang chủ là Severity thấp nhưng Priority cao trước buổi ra mắt.
4. Bằng chứng: ít mà đủ
- Ảnh chụp: khoanh vùng lỗi, giữ thanh địa chỉ để thấy URL.
- Video ngắn (dưới 30 giây) cho lỗi có nhiều bước hoặc liên quan thời gian.
- Console và Network: mở DevTools (F12), chụp lỗi đỏ trong Console; với lỗi API, copy request (Copy as cURL) và response. Một dòng
500 Internal Server Errorkèm response body thường giúp dev sửa nhanh hơn mười ảnh chụp. - Che thông tin nhạy cảm: token, mật khẩu, số thẻ, dữ liệu khách hàng thật.
5. 10 lỗi hay gặp
- Tiêu đề kiểu "Lỗi trang đăng ký" hay "Không chạy được".
- Gộp nhiều bug vào một ticket. Mỗi bug một ticket, link với nhau nếu liên quan.
- Thiếu kết quả mong đợi, hoặc mong đợi theo ý thích cá nhân thay vì đặc tả.
- Không ghi môi trường, bản build.
- Các bước bắt đầu từ giữa chừng ("ở màn hình thanh toán, bấm...").
- Viết "đôi khi bị lỗi" mà không có tần suất.
- Không tìm bug trùng trước khi tạo.
- Mô tả cảm xúc ("rất tệ", "nghiêm trọng!!!") thay vì dữ kiện.
- Đặt Blocker cho mọi thứ: sau vài lần, không ai tin nhãn của bạn nữa.
- Không kiểm lại khi dev báo đã sửa (retest) và không chạy lại các luồng liên quan (regression).
6. Mẫu copy vào Jira
*Môi trường:* staging v__, Chrome __, Windows __
*Điều kiện trước:*
*Các bước:*
#
#
#
*Kết quả thực tế:*
*Kết quả mong đợi:* (nguồn: )
*Tần suất:* _/_ lần
*Bằng chứng:*
Viết bug report tốt là kỹ năng giao tiếp nhiều hơn kỹ năng kỹ thuật: bạn đang viết cho một người bận rộn, không ngồi cạnh bạn. Càng ít câu hỏi ngược lại, bug càng được sửa nhanh.
Mình có một checklist kiểm thử web tiếng Việt miễn phí (form, đăng nhập, dữ liệu test tiếng Việt) để tìm bug có hệ thống hơn: https://github.com/qakit-vn/checklist-kiem-thu-web (kèm công cụ tạo test case miễn phí ngay trên trình duyệt: https://qakit-vn.github.io/qakit/tao-test-case.html)
All rights reserved
