Bài viết được sự cho phép của vntesters.com
Report bug là công việc thường xuyên và liên tục của một người làm test. Nhưng đã bao giờ bạn nghĩ mình có thể làm gì để một bug report trở nên hoàn chỉnh, ngắn gọn cũng như thể hiện sự chuyên nghiệp và rõ ràng trong từng report được gởi ra cho Dev? Hay nói một cách khác bạn đã bao giờ nghĩ làm sao để viết một bug report tốt.
Bài này mình chia sẻ những kinh nghiệm của bản thân trong việc làm sao để viết một bug report tốt. Hy vọng sẽ giúp ích cho các bạn.
Một mẫu report bug tham khảo
Bug ID: ————-
Date: —————
Assigned to:———
Status: ————-
Title: ————————————–
Summary/Description: ————————
Environments (OS/Browser): ——————
Step to reproduce:
1.
2.
3.
Actual results: —————————–
Expected results: —————————
Severity: ———————————–
Priority Level: —————————–
Tiêu đề (Bug Title)
- Miên tả ngắn gọn, thể hiện được lỗi. Tiêu đề tốt còn có thể giúp Dev biết được lỗi mà không cần xem các bước bên trong
- Có thể sử dụng cấu trúc dạng: What…When/Where…. Thể hiễn lỗi trước sau đó đến vị trí của lỗi
- Không nói chung chung
Ví dụ:
- Good Title: Missing the username & password label at Login form
- Good Title: [Authentication] The logout button does not clickable at Homepage
- Bad Title: The logout button does not work
- Bad Title: Something wrong with the register function
Mô tả lỗi (Summary)
Đây là nơi bạn có thể diễn tả rõ hơn về lỗi, không giống như tiêu đề bị gò bó bởi chiều dài, tại summary bạn có thể diễn tả dài hơn.
Tuy nhiên nếu lỗi đơn giản bạn có thể không cần ghì hoặc sao chép lại tiêu đề. Không nhất thiết phải cố gắng diễn tả dài dòng khi lỗi nó chỉ cần chừng đó thông tin là đủ.
Các bước tái tạo (Reproduce / Steps)
- Các bước nên đánh thứ tự 1-2-3
- Ngắn gọn, diễn tả một hành động, không nên ghi dài
- Đảm bảo các bước đúng thứ tự và có thể tái tạo được
Ví dụ:
- Enter admin email
- Enter admin password
- Click on change profile
- Upload the photo with GIF format
- Check the uploaded photo
Một số trường (field) thường gặp
Actual / Expected (Kết quả thật tế / Kết quả mong muốn)
- Ngắn gọn
- Thể hiện chính xác mong muốn trong phần expected.
Bad Expected: Change the text color
Good Expected: Change the text color to red (#E52121)
Bad Expected: Add the label to username
Good Expected: Add the label “Username” to the username field.
Một chú ý nhỏ nữa nhưng cũng góp phần quan trọng trong việc tạo cảm giác tốt cho dev là tránh ghi trực tiếp và đề cập đến con người trong đó.
Không nên: You need to fix the bug
Nên: The bug should be fixed
Không nên: Can you change the header text to bold?
Nên: The header text color should be in bold.
Các viết thứ hai sẽ không đề cập đến con người (You need, you must…) mà chỉ tập trung vào vấn đề.
Gợi ý:
- Nên đính kèm ảnh, hình ảnh sẽ giúp Dev hiểu rõ vấn đề hơn, đôi khi không cần đọc các bước.
- Hạn chế video: khá nặng và tốn nhiều thời gian để xem, chỉ dùng trong các lỗi phức tạp.
- Phân biệt và dùng đúng mức độ priority và severity.
- Không phải các bug đều được report bằng chữ, bạn có thể report và làm việc trực tiếp với Dev. Có nhiều lỗi bạn cần và cũng nên chia sẻ thông qua giao tiếp & làm việc nhóm.
- Kiểm tra kĩ trước khi report, tránh report trùng hoặc không phải là lỗi.
- Không nên gộp nhiều lỗi vào 1 report, mỗi report chỉ nên xử lý một vấn đề.
- Ghi rõ môi trường + phiên bản đang test.
Vậy tổng kết, thế nào là một bug report hiệu quả?
- Có thể tái tạo lại được bởi developer
- Ngắn ngọn, tiết kiệm thời gian
- Đầy đủ thông tin, hình ảnh
- Độc lập, có thể theo dõi được từng lỗi
Mình rất muốn nghe chia sẻ thêm từ những kinh nghiệm của các bạn trong việc viết một bug report tốt và hiệu quả, nếu có gì muốn chia sẻ hay bổ sung các bạn để lại comment nhé!
Bài viết gốc được đăng tải tại vntesters.com
Có thể bạn quan tâm:
