Nội dung bài học
Đối với mỗi Tester, việc kiểm tra sản phẩm và báo cáo lỗi là việc làm thường xuyên và liên tục nhưng không phải ai cũng biết cách tự thẩm tra lại đó có chính xác là Bug không và làm cách nào viết Bug report một cách hiệu quả.
Cái này thì chắc chỉ có cách làm nhiều năm rồi tự nhận thức được, học hỏi nhiều đàn anh đàn chị chỉ dạy lại những lần sai thì mới tăng kiến thức vững được. Hi trước An cũng thế. Mới làm Tester ngáo ngơ hahaaha 
Dưới đây Anh Tester chia sẻ một số kinh nghiệm của bản thân và tham khảo thêm hi vọng có thể giúp ích cho các bạn.
1. Bug report là gì?
Bug report là mô tả lỗi xảy ra khi thực thi test phần mềm, thường hay được Dev nhà mình gọi vui là log Bug hay report Bug. Bug report thường được Tester thực hiện 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
2. Tại sao phải viết Bug report tốt?
- Để 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” vô hình tạo cho Dev một ấn tượng, sự tin tưởng về kết quả test của Tester và những Bug mà Tester log lên. Khi đó, sẽ tránh được một vài xung đột không đáng có 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 của mình hơn.
- Nâng cao kỹ năng của Tester.
3. Làm thế nào để đánh giá được Bug report có tốt hay không?
Ai cũng có thể viết Bug report nhưng không phải ai cũng viết report hiệu quả để Dev có thể tái hiện được, chấp nhận Bug và thực hiện fix.
Vậy làm thế nào để có thể phân biệt được Bug report có chất lượng tốt và chất lượng trung bình? Dưới đây là một vài tiêu chí đánh giá tiêu biểu để xác định:
| Bug report chất lượng tốt | Bug report chất lượng trung bình |
| Chứa đầy đủ thông tin về vấn đề cần sửa | Thiếu thông tin hoặc thông tin không rõ ràng |
| Có thể tái hiện được | Không thể tái hiện |
| Tạo nên được tiền đề phối hợp giữa Dev và Tester | Gây tranh cãi hoặc không hợp tác giữa Dev và Tester |
| Bug được sửa nhanh | Bug không được sửa |
4. Cấu trúc report bug
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 baó 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
Ví dụ về một bug report trên phần mềm Jira
5. Làm thế nào để viết được một Bug report tốt?
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. Có thể bao gồm các thông tin sau: {ScreenID} – {Function Description} – {UTCaseID_Index}
- 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 (như môi trường local, môi trường staging,…) để 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ó tiếng nói chung cũng như Dev hiểu được mong muốn về chất lượng phần mềm của Tester thì Tester nên ghi rõ phần này.
- 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ế
Ví dụ:
6. Một số mẹo và thủ thuật dành cho bạn
- 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 thì ta nên chụp ngay lại ảnh màn hình lưu lại để báo cáo sau khi xác nhận Bug.
- Xác nhận lại Bug: để không bị log Bug “nhầm” thì trước khi báo cáo nên kiểm tra xem đó có chính xác là Bug hay không bằng cách xóa bộ nhớ cache (Ctrl +F5), kiểm tra log server, kiểm tra console log, kiểm tra database, kiểm tra trên module tương tự khác …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: có nghĩa là sau khi gặp và đã xác định đó là Bug thì nên báo cáo luôn, không chờ viết Bug report xong hoặc test xong phần đó rồi mới báo cáo. Điều này đả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: Đây là phần quan trọng chỉ sau phần tiêu đề. Nên mô tả lỗi ngắn gọn. Các bước nên đánh thứ tự 1-2-3…, mỗi step chỉ mô tả một hành động, không viết dài quá. Mục tiêu là khi đưa Bug report cho một người không biết gì thực hiện theo các mô tả có thể tái hiện được Bug đó.
- Không sử dụng ngôn ngữ gây tổn thương người đọc:nếu không phải là Bug thì nên gọi là vấn đề của chức năng nào đó, không đánh đồng gọi là Bug gây ảnh hưởng tới tâm lý người làm task.
- Bug khó tái hiện: trường hợp không thể tái hiện lỗi giống nhau trên máy Dev và Tester thì nê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.
7. Một số phần mềm hỗ trợ
Phần mềm hỗ trợ kiểm tra và xác nhận lỗi
- Dùng console log trong chrome dev tool tìm hiểu thêm tại đây
- CHROME EXTENSIONS HỮU ÍCH DÀNH CHO TESTER
Phần mềm hỗ trợ chụp ảnh/ quay video:
- Snagit: download tại đây
- Lightshot: download tại đây
- Awesome screenshot screen video recorder chrome: thêm tiện ích tại đây
Tóm lại, thế nào là một bug report hiệu quả?
- 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 của bản thân và tham khảo thêm rất mong nhận được sự chia sẻ và bổ sung ý kiến từ các bạn. Chúc các bạn viết Bug report hiệu quả!
Zalo
Anh Tester
facebook.com/anhtester
Đường dẫu khó chân vẫn cần bước đi
Đời dẫu khổ tâm vẫn cần nghĩ thấu