Log Bug Hiệu Quả: Từ Phát Hiện Đến Ghi Chép Chuẩn Cho Fresher
7 tháng trước · 11 phút đọc
Bug report bị reject - câu chuyện ai cũng từng gặp
Mình nhớ lần đầu log bug cho tính năng đăng nhập. Viết xong tự thấy rất ổn: "Nhấn đăng nhập bị lỗi". Gửi lên Jira. Hai tiếng sau dev comment: "Reproduce không ra, close."
Khó chịu. Nhưng nhìn lại - lỗi hoàn toàn ở phía mình.
Một bug report tệ không giúp ai. Dev không biết làm lại bước nào, không rõ kỳ vọng đúng là gì, không có môi trường để test. Kết quả? Bug bị close, tính năng lỗi vẫn lên production, người dùng chịu. Vòng tròn ấy xảy ra nhiều hơn bạn nghĩ.
Bài này mình đi từ đầu: bug là gì, phát hiện như thế nào, rồi ghi chép ra sao cho chuẩn. Đọc xong bạn có ngay mẫu Excel để dùng luôn.
Bug report mơ hồ = dev không reproduce = lỗi vẫn live
Bug là gì và làm sao nhận ra nó?
Bug là sự khác biệt giữa kết quả thực tế và kết quả mong đợi. Đơn giản vậy thôi.
Không cần biết code. Không cần hiểu tại sao lỗi xảy ra. Nhiệm vụ của tester là nhận ra "cái này sai", không phải giải thích tại sao sai.
Một số dấu hiệu phổ biến:
- Màn hình trắng hoặc đứng im khi thực hiện thao tác
- Thông báo lỗi xuất hiện không đúng lúc (hoặc không xuất hiện khi cần)
- Dữ liệu hiển thị sai: số tiền, tên người dùng, ngày tháng
- Tính năng hoạt động ở bước này nhưng không hoạt động ở bước khác
- Giao diện vỡ layout trên một kích thước màn hình cụ thể
Tester không cần biết code - chỉ cần nhận ra "điều này sai"
Bước quan trọng trước khi log bug: reproduce lại ít nhất 2-3 lần. Một lỗi xảy ra 1 lần rồi biến mất có thể là lỗi mạng, lỗi cache tạm thời, hoặc bạn thao tác nhầm. Log bug mà không reproduce được là lãng phí thời gian của cả team.
Nếu reproduce được ổn định - đó là bug thật. Bắt đầu ghi chép.
Severity và Priority: đừng nhầm hai khái niệm này
Đây là điểm fresher hay nhầm nhất. Mình giải thích thẳng:
Severity (mức độ nghiêm trọng) - lỗi ảnh hưởng đến hệ thống như thế nào về mặt kỹ thuật.
Priority (mức độ ưu tiên) - lỗi cần fix sớm đến mức nào về mặt business.
Hai cái này có thể ngược nhau. Ví dụ thực tế:
| Tình huống | Severity | Priority |
|---|---|---|
| Crash app khi thanh toán | Critical | High |
| Logo bị lệch 2px trang chủ | Low | Low |
| Lỗi chính tả tên CEO trên About Us | Low | High (sắp ra sự kiện) |
| Tính năng ẩn không ai dùng bị lỗi | High | Low |
Trường hợp thứ ba mình thấy nhiều nhất. Lỗi nhỏ về UI, nhưng CEO chuẩn bị demo cho đối tác ngày mai - priority lên ngay mức Urgent dù severity chỉ là Low.
Severity và Priority khác nhau - fresher hay nhầm đây
Các mức Severity thường dùng:
- Critical: App crash, mất dữ liệu, không thể sử dụng tính năng chính
- Major: Tính năng quan trọng bị lỗi nhưng có workaround
- Minor: Lỗi nhỏ, tính năng vẫn hoạt động được
- Trivial: Lỗi giao diện, chính tả, không ảnh hưởng chức năng
Khi mới vào, bạn chịu trách nhiệm đánh Severity. Priority thường do PM hoặc lead quyết định. Đừng tự ý đặt Priority quá cao mà không có lý do - sẽ mất uy tín dần.
Cấu trúc một bug report chuẩn
Bug report tốt phải đủ để một người chưa biết gì về lỗi đó cũng reproduce được. Mình test chuẩn này bằng cách tưởng tượng: "Nếu mình đưa bản này cho người mới join hôm nay, họ có thể làm lại không?"
Các trường bắt buộc:
1. Bug ID - mã định danh, Jira hoặc Excel tự sinh
2. Tiêu đề (Summary) - ngắn gọn, đủ ý, không viết kiểu "bị lỗi"
- ❌ Sai: "Trang đăng nhập lỗi"
- ✅ Đúng: "[iOS 17] Nút Đăng nhập không phản hồi khi nhập đúng email/password lần đầu"
3. Steps to reproduce - từng bước, đánh số rõ ràng
1. Mở app trên iPhone 13, iOS 17.2
2. Vào màn hình Đăng nhập
3. Nhập email: [email protected]
4. Nhập password: Test@1234
5. Tap nút Đăng nhập
4. Expected result - kết quả đúng phải là gì
Chuyển sang màn hình Dashboard sau 1-2 giây
5. Actual result - thực tế đang xảy ra gì
Nút không phản hồi, không có thông báo lỗi, app không chuyển màn hình
6. Severity - theo thang đã nói ở trên
7. Môi trường (Environment) - thiếu phần này dev hay reject nhất
OS: iOS 17.2 | Device: iPhone 13 | App version: 2.1.3 | Browser: Safari (nếu web)
8. Attachment - screenshot hoặc video màn hình. Video ngắn 10-20 giây tốt hơn nhiều ảnh chụp.
Steps to reproduce rõ ràng = dev fix đúng lần đầu, không hỏi thêm
Một mẹo nhỏ: khi chụp screenshot, dùng tool annotate (vẽ khoanh tròn, mũi tên) highlight đúng chỗ lỗi. Đừng gửi ảnh full màn hình mà không đánh dấu gì - dev phải đoán bạn đang nói chỗ nào.
Mẫu log bug bằng Excel - đơn giản, dùng được ngay
Nhiều team nhỏ và startup Việt Nam không dùng Jira - họ dùng Google Sheets hoặc Excel để track bug. Biết cách setup file này giúp bạn làm việc ngay mà không cần chờ tool.
Mình để mẫu Excel bên dưới, gồm các cột:
- Bug ID: BUG-001, BUG-002 (tự đặt hoặc dùng công thức tự động)
- Tiêu đề: Summary ngắn gọn
- Module: Phần nào của app (Login, Payment, Profile...)
- Steps to Reproduce: Ghi gọn, có thể dùng dấu gạch đầu dòng
- Expected / Actual: Hai cột riêng
- Severity: Dropdown (Critical / Major / Minor / Trivial)
- Priority: Dropdown (High / Medium / Low)
- Status: Open / In Progress / Fixed / Closed
- Assigned To: Dev nào xử lý
- Found Date / Fixed Date: Để track thời gian
- Attachment: Link ảnh/video (upload Google Drive, paste link vào)
- Note: Thông tin thêm, workaround nếu có
Tải mẫu log bug Excel (HTML interactive)
File Excel đơn giản nhưng đủ dùng cho team nhỏ và fresher mới đi làm
Mẹo khi dùng Excel thay Jira: tạo tab riêng cho từng sprint hoặc từng tháng. Đừng để tất cả trong 1 sheet dài vô tận - sẽ rất khó lọc và báo cáo sau này.
Nếu team bạn dùng Jira, cấu trúc tương tự nhưng có thêm tính năng link bug với task, filter tự động, và thống kê. Khóa Kiểm thử phần mềm có phần hướng dẫn thực hành Jira cho tester nếu bạn muốn tìm hiểu thêm.
Log bug với Postman - dành cho tester test API
Nếu bạn đang test API, bug report cần thêm vài trường so với test UI thông thường. Dev cần thấy đúng request bạn gửi và response trả về - không có cái này họ không thể debug.
Cấu trúc bug report API:
Endpoint: POST /api/v1/users/login
Method: POST
Headers: Content-Type: application/json
Request body:
{
"email": "[email protected]",
"password": "Test@1234"
}
Expected response (HTTP 200):
{
"status": "success",
"token": "..."
}
Actual response (HTTP 500):
{
"error": "Internal Server Error"
}
Bug report API cần đủ request + response - thiếu một trong hai là dev không debug được
Trong Postman, bạn có thể dùng Export để lưu collection hoặc chụp màn hình response panel. Khi log bug API:
- Chụp screenshot Postman với request đầy đủ (URL, headers, body)
- Chụp thêm response tab (status code, body trả về)
- Paste cả 2 vào bug report
- Nếu có token auth, ghi rõ token còn hiệu lực không (thêm trường "Token expires at")
Một lỗi mình hay thấy fresher làm: log bug API mà chỉ nói "API lỗi" không kèm request/response. Dev nhìn vào không biết bắt đầu từ đâu. Tệ hơn là khi bạn test lại, cái bug đó có khi đã tự fix (do server restart, cache clear...) và không ai reproduce được nữa.
Những lý do phổ biến khiến bug bị reject
Bug bị reject không hẳn là dev khó tính. Phần lớn do bug report chưa đủ thông tin. Mình tổng hợp từ kinh nghiệm thực tế:
"Cannot reproduce" - lý do số 1. Thiếu steps rõ ràng, thiếu môi trường, hoặc bạn chỉ reproduce được 1 lần. Fix: thêm video recording, ghi rõ version và device.
"This is by design" - tính năng đang hoạt động đúng theo yêu cầu ban đầu, chỉ là bạn chưa đọc spec. Fix: kiểm tra requirements document hoặc hỏi PM trước khi log.
"Duplicate" - bug này đã được log rồi. Fix: search bug list trước khi tạo mới.
"Not enough info" - thiếu expected result, thiếu môi trường, hoặc tiêu đề quá mơ hồ. Fix: dùng checklist trước khi submit.
4 lý do bug bị reject và cách khắc phục - save lại để check trước khi submit
Checklist trước khi submit bất kỳ bug nào:
- [ ] Đã reproduce ít nhất 2 lần?
- [ ] Tiêu đề mô tả đúng vấn đề, không chung chung?
- [ ] Steps to reproduce đủ để người khác làm theo?
- [ ] Expected result và Actual result điền cả hai?
- [ ] Đã điền môi trường (OS, version, device)?
- [ ] Có screenshot hoặc video đính kèm?
- [ ] Đã search xem bug này tồn tại chưa?
Thấy khó nhớ lúc đầu là bình thường - mình cũng mất 2-3 tuần mới thành thói quen. Bookmark checklist này, mở ra check mỗi lần submit là được.
Bắt đầu thực hành ngay hôm nay
Kiến thức về log bug chỉ thật sự thấm khi bạn tự làm. Mình hay gợi ý người mới học thực hành theo cách này:
Tìm một app bạn dùng hàng ngày - Shopee, Grab, hoặc bất kỳ app nào. Dành 30 phút dùng như user bình thường, nhưng lần này chú ý xem có gì bất thường không. Khi thấy gì đó khác kỳ vọng, thử log bug theo cấu trúc mình đã chia sẻ - ngay cả khi chỉ để luyện tập, không gửi cho ai.
Làm vài lần như vậy, bạn sẽ thấy viết steps to reproduce trở nên tự nhiên hơn hẳn.
Tóm lại, để log bug không bị reject:
- Reproduce ít nhất 2 lần trước khi log
- Tiêu đề cụ thể: nền tảng, tính năng, triệu chứng
- Steps to reproduce đủ để người lạ làm theo
- Điền đủ expected/actual result và môi trường
- Đính kèm screenshot/video có highlight vùng lỗi
- Search trùng lặp trước khi submit
Luyện log bug trên app thật - không cần project thật để bắt đầu
Bài tiếp theo mình sẽ hướng dẫn viết test case cho tính năng đăng nhập - từ happy path đến edge case hay bị bỏ sót nhất. Bookmark để theo dõi nhé!
Nếu bạn muốn có nền tảng bài bản hơn về kiểm thử phần mềm, khóa Kiểm thử phần mềm đi từ căn bản đến thực chiến, tập trung đúng kiến thức trọng tâm để đi làm được sau 2 tháng.