Hình ảnh minh họa viết Bug report chất lượng | Anh Tester
Bug report là mô tả lỗi xảy ra khi thực thi test phần mềm. Thông thường, nó được gọi là log Bug hoặc report Bug. Tester thường thực hiện Bug report trên các phần mềm quản lý tasks như Gitlab, Jira, Redmine,...
Tìm hiểu: Vòng đời của Bug/Defect trong Kiểm thử phần mềm.
- Để Dev có thể tái hiện Bug dễ dàng.
- Tỷ lệ Bug được fix sẽ cao hơn.
- Đưa ra một sản phẩm chất lượng tốt hơn.
- Nâng cao khả năng Teamwork. Khi Tester viết Bug report "chất lượng", Dev sẽ có ấn tượng và tin tưởng vào kết quả test của Tester. Điều này giúp tránh xung đột giữa Dev và Tester khi Tester trả về bug.
- Nâng cao kỹ năng code của Dev. Sau mỗi Bug bị trả về, Dev sẽ có thêm kinh nghiệm cover code.
- Nâng cao kỹ năng của Tester.
Bất kỳ ai cũng có thể viết Bug report, nhưng viết report hiệu quả để Dev có thể tái hiện được Bug và fix là không dễ. Dưới đây là một số tiêu chí đánh giá Bug report chất lượng:
Bug report chất lượng tốt:
- Chứa đầy đủ thông tin về vấn đề cần sửa.
- Có thể tái hiện được.
- Tạo nên được tiền đề phối hợp giữa Dev và Tester.
- Bug được sửa nhanh.
Bug report chất lượng trung bình:
- Thiếu thông tin hoặc thông tin không rõ ràng.
- Không thể tái hiện.
- Gây tranh cãi hoặc không hợp tác giữa Dev và Tester.
- Bug không được sửa.
Khi log bug, cần lưu ý các điểm sau:
- What: Bug này là bug gì, độ nghiêm trọng của nó như thế nào?
- Where: Xác định lỗi ở đâu, trên môi trường nào (web thì browser nào, app thì trên hệ điều hành nào).
- When: Bug xảy ra khi nào (nghĩa là thực hiện những bước nào thì xảy ra Bug).
- How: Hướng sửa Bug đó như thế nào? (expected result).
- Who: Bug do code của ai gây ra.
Format report bug:
- Project Code: Dự án hay sản phẩm xuất hiện bug.
- Defect ID: tên bug.
- Title: Miêu tả ngắn gọn bug.
- Description: Miêu tả chi tiết bug.
- Severity: Mức độ nguy hại của bug.
- Type: Phân loại bug.
- Status: Trạng thái hiện tại của bug.
- Stage detected: Phạm vi hoạt động của dự án xác định vòng đời khi lỗi được phát hiện.
- Activity: Các bước mô tả.
- Process origin: Tên hay mã nguồn của đoạn phần mềm mà trong đó bug là nguồn gốc.
- Priority: Độ ưu tiên.
- Creator: Người phát hiện bug.
- Create date: Ngày báo cáo bug.
- Assign to: Người chịu trách nhiệm về bug.
- Due date: Hạn chót cho việc hoàn thành bug.
- Close date: Ngày close bug.
- Attached: Ảnh hoặc video mô tả.
Ví dụ: Báo cáo lỗi.
Các bạn có thể tham khảo các nội dung sau:
- Bug title: ngắn gọn, xúc tích mà bao trọn được nội dung.
- Hiện tượng: có cái nhìn tổng quan về hiện tượng xảy ra của Bug, có thể có ảnh chụp màn hình kèm theo để Dev có cái nhìn trực quan hơn.
- Môi trường: Nên viết mô tả đầy đủ, chính xác hiện tượng xảy ra ở môi trường nào để Dev hoặc người đọc xác nhận được Bug nhanh và chính xác hơn.
- Kỳ vọng về kết quả sau khi fix của bug là gì? Để Dev và Tester cùng nhìn nhận về chất lượng phần mềm.
- Các bước tái hiện: ghi thành các bước rõ ràng, mỗi bước tương ứng với một thao tác cụ thể.
- Trạng thái của Bug: Khi Tester vừa tạo Bug report, trạng thái của Bug là "New". Sau đó sẽ có các trạng thái tương ứng như Resolved - Bug đã được fix, Done - Bug đã được Tester test, Reopen - Sau khi Dev fix, Tester re-test vẫn còn lỗi.
- Mức độ ưu tiên của Bug: Khi nào Bug nên được fix? Độ ưu tiên thường quy định từ P1 đến P5 theo thứ tự tăng dần. Trường hợp Bug chỉ gặp trên 1 số máy cụ thể, hoặc có độ ưu tiên thấp thì nên đánh độ ưu tiên của Bug thấp để xử lý sau.
- Assign: Nếu Tester biết ai sẽ sửa thì gắn tên của Dev vào Bug tương ứng.
- Phiên bản (nếu có).
- Tác vụ cha (nếu có).
- Ngày bắt đầu: Ngày Dev bắt đầu thực hiện fix.
- Ngày hết hạn: Ngày kết thúc việc sửa thực tế.
- Chụp lại ảnh ngay khi gặp Bug hoặc hiện tượng lạ để tránh trường hợp Bug khó tái hiện.
- Xác nhận lại Bug để không bị log Bug "nhầm" bằng cách kiểm tra log server, kiểm tra console log, kiểm tra database, và tự tái hiện Bug 3 lần trước khi báo cáo.
- Báo cáo ngay lập tức để đảm bảo không bị thiếu Bug và có thể tái hiện được.
- Viết tóm tắt lỗi rõ ràng để dễ hiểu và tái hiện được Bug.
- Không sử dụng ngôn ngữ gây tổn thương người đọc.
- Bug khó tái hiện: Dùng máy thứ 3 để tái hiện, như vậy sẽ đánh giá được chính xác lỗi hơn.
Phần mềm hỗ trợ kiểm tra và xác nhận lỗi:
- Console log trong Chrome Dev tool.
- Chrome Extensions hữu ích dành cho Tester.
Phần mềm hỗ trợ chụp ảnh/quay video:
- Snagit.
- Lightshot.
- Awesome screenshot screen video recorder chrome.
- Dễ dàng tái hiện bởi Dev hoặc người đọc.
- Report ngắn gọn, rõ ràng.
- Đầy đủ thông tin, hình ảnh.
- Dễ dàng theo dõi, truy vấn bug khi cần.
- Khả năng được fix cao.
Trên đây là những kinh nghiệm và tham khảo để viết Bug report hiệu quả. Hy vọng bạn đã tìm thấy thông tin hữu ích để cải thiện quy trình của mình.
