Chạy test case thấy actual khác expected, phản xạ đầu tiên thường là:
Bug rồi, log thôi.
Khoan một nhịp. Màn hình đứng im có thể là bug, cũng có thể build đang deploy dở, account hết quyền, data sai, network chết hoặc test case cũ hơn requirement. Việc đầu tiên không phải mở Jira, mà là xác nhận mình vừa nhìn thấy cái gì.
Trước khi log
Mình thường kiểm tra nhanh:
- Reproduce lại ít nhất một lần nếu điều kiện cho phép.
- So với requirement, acceptance criteria và thiết kế hiện tại.
- Kiểm tra đúng build, environment, account và test data chưa.
- Xem console, network hoặc log nếu có quyền và nó giúp khoanh vùng.
- Tìm bug cũ để tránh duplicate.
Không cần điều tra tới mức sửa hộ dev rồi mới được log. Mục tiêu là loại các nhầm lẫn rẻ tiền và thu đủ dữ kiện để người nhận bắt đầu làm việc.
Một bug report cơ bản
Template tùy tool, nhưng nội dung thường cần:
| Trường | Câu hỏi nó phải trả lời |
|---|---|
| Title | Cái gì sai, ở đâu, trong điều kiện nào? |
| Environment/Build | Failure xuất hiện trên phiên bản và môi trường nào? |
| Preconditions | State nào phải có trước khi reproduce? |
| Steps to Reproduce | Làm gì để failure xuất hiện? |
| Actual Result | Thực tế quan sát được gì? |
| Expected Result | Theo test basis thì đáng lẽ phải thế nào? |
| Evidence | Ảnh, video, request, response, console hoặc log nào hỗ trợ? |
| Severity/Priority | Ảnh hưởng nặng ra sao và cần xử lý gấp đến đâu? |
Tool sẽ tự ghi ID, người tạo và thời gian. Đừng copy mấy thứ tool đã biết vào Description cho dài.
Ví dụ
Giả sử account active dùng đúng email và password nhưng bấm Login không chuyển trang.
Title
[Login] Active user remains on Login page after submitting valid credentialsTitle kiểu Login not working ngắn thật, nhưng dev đọc xong vẫn phải hỏi login bằng cách nào, account gì và fail ở đâu.
Environment
Environment: Staging
Build: 2026.08.09-rc.3
Browser: Chrome 127 / Windows 11
Account: active user, MFA disabledChỉ ghi những gì có khả năng liên quan. Bug API không cần khai kích thước màn hình nếu nó chẳng ảnh hưởng gì.
Steps to Reproduce
- Mở trang Login.
- Nhập email của account active.
- Nhập password hợp lệ.
- Bấm Login.
Actual Result
Button chuyển sang trạng thái loading khoảng 1 giây rồi trở lại bình thường.
User vẫn ở trang Login. Request POST /sessions trả HTTP 500 với errorId abc-123.Expected Result
Session được tạo và user được chuyển tới /dashboard.Actual chỉ viết thứ đã quan sát. “Backend bị null pointer” không phải actual nếu mình chưa có log chứng minh. Expected cũng đừng viết bằng phủ định kiểu “không được đứng im”; nói rõ hành vi đúng là gì.
Evidence dùng cái gì?
Ảnh phù hợp với lỗi tĩnh: layout vỡ, text sai, state hiển thị không đúng. Video phù hợp với timing, animation, redirect hoặc failure chỉ lóe lên rồi biến mất.
Với API và web app, request/response, status code, timestamp, correlation ID và console error thường có giá trị hơn một tấm ảnh đỏ lòm. Nhưng nhớ che token, password, cookie, dữ liệu cá nhân và thông tin khách hàng trước khi đính kèm.
Evidence chứng minh failure, không thay thế Steps, Actual và Expected. Ném video ba phút không chú thích rồi bảo dev tự xem là đang chuyển việc viết bug report sang người khác.
Severity và Priority
- Severity: failure hoặc defect ảnh hưởng nặng tới đâu.
- Priority: business muốn xử lý nó gấp tới đâu.
Hai giá trị có liên quan nhưng không khóa cứng vào nhau.
Bug làm app crash sau 20 giờ chạy liên tục có severity cao, nhưng priority có thể chưa cao nhất nếu occurrence hiếm và team đang xử lý lỗi thanh toán xảy ra mỗi phút.
Banner chiến dịch bị sai logo có severity chức năng thấp, nhưng chiến dịch lên sóng sáng mai thì priority có thể nhảy lên đầu hàng.
Ai được set giá trị nào tùy workflow. Có team tester đề xuất severity, Product Owner quyết priority; có team triage chung. Định nghĩa Critical, High, P0 cũng phải theo dự án, không bê SLA trên mạng về dùng như luật quốc tế.
Defect workflow
Một flow đơn giản có thể là:
Tên status thay đổi theo tool, nhưng ý chính giống nhau:
- Bug mới cần được triage.
- Bug hợp lệ được gán người xử lý hoặc đưa vào backlog.
- Dev báo fixed chưa có nghĩa bug tự closed.
- Tester hoặc người phụ trách confirmation test lại đúng build.
- Failure vẫn còn thì reopen kèm evidence mới.
Rejected không phải lúc nào cũng có nghĩa tester log ngu. Nó có thể là duplicate, works as designed, cannot reproduce hoặc business chấp nhận rủi ro. Quan trọng là lý do phải được ghi lại, không phải đóng ticket bằng một chữ Invalid rồi biến mất.
Bug report và bài viết chuyên sâu
Bài này chỉ đặt template nền để series đi tiếp. Mình đã có một bài riêng đi sâu vào chuyện title, reproduce, evidence, log và cách trao đổi để ticket không biến thành trận tennis giữa dev với tester:
Đọc cả hai sẽ hơi trùng vài khái niệm, nhưng một bài thuộc flow nhập môn, bài kia đi vào cách làm cho report thực sự hữu dụng trong team.
Chốt lại
Bug report tốt không cần văn hoa. Nó cần reproduce được, phân biệt rõ actual với expected, chỉ đúng build và mang đủ evidence mà không làm lộ dữ liệu nhạy cảm.
Bài tiếp theo sẽ nói về report trong testing. Bug ticket mô tả từng vấn đề; test report phải gom cả tiến độ, coverage, defect và risk thành bức tranh để người khác ra quyết định.
