- Tại sao phải report bug “chất lượng”
- Để Dev có thể tái hiện bug dễ dàng
- Đỡ tốn thời gian trao đổi qua lại giữa Dev va Tester
- 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 sự tin tưởng của Dev, cụ thể khi Tester viết bug “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
- Nâng cao kỹ năng code của Dev. Dev sẽ có thêm kinh nghiệm cover code của mình hơn, tránh lặp lại bug tương tự ở trong tương lai
2. Nguyên tắc khi report bug
- Tránh log trùng bug khi dự án có từ 2 tester trở lên
- Tránh viết gộp nhiều bug nhỏ thành 1 bug lớn, chỉ nên gộp với những trường hợp bug có liên quan mật thiết với nhau, còn không, nên tách riêng để việc kiểm soát bug cũng như fix bug hiệu quả và rõ ràng hơn.
- Bug viết phải dễ hiểu, dễ tái hiện: lý do nói ở trên
- Quản lý được bug: khi tham gia bất kì dự án nào, bạn cần check và quản lý bug lên 1 công cụ, tránh log lên nhiều công cụ dẫn đến việc không thể kiểm soát được bug, từ đó gây ảnh hưởng đến chất lượng dự án
- Bằng chứng cụ thể: phải có dẫn chứng cụ thể (hình ảnh, video) để report bug có tính thuyết phục cao hơn, ví dụ như bug về UI mà khó diễn đạt bằng lời, thì nên chụp ảnh và khoanh vùng chỗ lỗi, còn phức tạp hơn, hãy quay lại video để có thể diễn tả
- Bug được tái hiện ít nhất 2-3 lần trước khi quyết định log bug: hãy chắc chắn là tái hiện nó ít nhất 2-3 lần để đảm bảo đó là bug và tái hiện được vì đôi lúc nó bị lỗi là do chưa clear cache or 1 số lý do khách quan nào đó nhầm tưởng đó là bug.
- Kiểm tra sự xuất hiện của bug trên các module tương tự khác trong cùng 1 màn hình để tránh log bug bị trùng, gây cảm giác khó chịu cho Dev.
3. Cấu trúc report bug và chia sẻ kinh nghiệm log bug “chất lượng”
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:
- 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
- Status: Trạng thái hiện tại của bug
- Activity: Các bước mô tả
- 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
- Worker: Người gây ra bug
- Attached: ảnh hoặc video mô tả
Kinh nghiệm report bug “chất lượng”
- Bug title: ngắn gọn, xúc tích mà bao trọn được nội dung, gồm các thông tin sau: Web: [Browser][Function]<content> hoặc Mobile: [Platform][Browser][Function]<content>
Ví dụ: [Chrome][Login] Hiển thị sai nội dung message lỗi ở màn hình login khi user nhập sai UserID
- 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ó thể lấy dẫn chứng ở trong spec để tăng thêm tính thuyết phục
- 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.
- Worker: Điền rõ người gây ra bug để dễ dàng cho tracking bug
- Đính kèm: đính kèm link hoặc tên files như hình ảnh, mp3, gif, data, … tái hiện bug để nếu đọc xong phần Step to re-produce dev vẫn không hiểu thì có thể xem thêm phần tài liệu đính kèm để hiểu về bug.
