Yêu cầu khi viết Báo cáo Lỗi

Một báo cáo lỗi (bug report) tốt phải giúp người đọc hiểu đúng vấn đề mà không cần hỏi lại. Dưới đây là các yêu cầu bắt buộc khi điền form báo cáo lỗi, mỗi phần sẽ được giải thích kỹ hơn ở các mục bên dưới:

• Nếu báo cáo là functional bug (lỗi chức năng), phải chọn mức Severity (mức độ nghiêm trọng) trước khi điền các phần còn lại.
• Title (tiêu đề) cần tóm tắt được lỗi: chuyện gì xảy ra, xảy ra ở đâu, và trong điều kiện nào. Người đọc chỉ cần nhìn tiêu đề là hiểu ngay vấn đề, không cần mở báo cáo ra xem.
• URL (đường dẫn) là địa chỉ đúng của trang xảy ra lỗi, lấy trực tiếp từ thanh địa chỉ trình duyệt.
• Ghi lại đầy đủ các bước để bất kỳ ai làm theo cũng tái hiện được lỗi.
• Actual Result (kết quả thực tế) mô tả điều thực sự xảy ra sau bước cuối cùng, không được viết lặp lại tiêu đề.
• Expected Result (kết quả kỳ vọng) là điều đáng lẽ phải xảy ra nếu sản phẩm không có lỗi.
• Đính kèm ảnh hoặc video để chứng minh lỗi có thật.
• Chọn đúng thiết bị và trình duyệt đã dùng để test trong phần Used Environment (môi trường sử dụng).

1. Form báo cáo lỗi

Sau khi chọn xong Feature, toàn bộ form báo cáo sẽ hiện ra. Mỗi trường trong form cần được điền đúng và đủ.

2. Mức độ nghiêm trọng (Severity)

Trường này chỉ xuất hiện với Functional bug (lỗi chức năng), gồm 3 mức: Low (thấp), High (cao), Critical (nghiêm trọng). Mức độ này thể hiện lỗi khẩn cấp tới đâu, dựa trên nhiều yếu tố khác nhau. Các loại bug khác sẽ không có trường Severity.

3. Tiêu đề (Title)

Người đọc chỉ cần nhìn tiêu đề là phải hình dung được vấn đề, không cần mở cả báo cáo ra. Một tiêu đề tốt cần trả lời được 3 câu hỏi:

• Chuyện gì xảy ra?
• Xảy ra ở đâu?
• Xảy ra khi nào, hoặc trong điều kiện gì?

Hãy mô tả đúng hành vi quan sát được, thay vì viết chung chung kiểu “không hoạt động”. Nếu lỗi chỉ xuất hiện trong một điều kiện cụ thể, hãy nêu rõ điều kiện đó ngay trong tiêu đề.

Một mẹo hữu ích: hãy tưởng tượng người đọc chưa từng test website hay app này, họ không biết bạn đang nói đến trang nào. Đọc lại tiêu đề dưới góc nhìn đó để kiểm tra xem đã đủ rõ ràng chưa.

Ví dụ tiêu đề

Đúng	Sai
Hiện thông báo lỗi ở trang Checkout khi đặt hàng bằng PayPal	Checkout không hoạt động
Trang Cart hiện lỗi 404 khi mở bởi người dùng đã đăng nhập	Trang Cart hiện lỗi 404

4. URL

Truy cập đúng trang xảy ra lỗi, sao chép URL từ trình duyệt và dán vào form. URL phải hợp lệ và trỏ đúng tới trang đó.

Ví dụ

Tình huống	URL đúng	URL sai
Nút “Thêm vào giỏ” không phản hồi trên trang chi tiết sản phẩm	URL của trang sản phẩm nơi bấm nút, ví dụ https://example.com/product/running-shoes	Bất kỳ URL trang khác
Một link dẫn tới trang 404	URL trang chứa link bị hỏng, ví dụ https://example.com/sale	URL của chính trang 404, ví dụ https://example.com/404

5. Các bước tái hiện lỗi (Steps to Reproduce)

Lỗi bắt buộc phải tái hiện được. Mỗi bước chỉ nên mô tả một hành động duy nhất, hệ thống sẽ tự đánh số nên bạn không cần làm việc đó.

Bước đầu tiên luôn phải nói rõ cách truy cập vào website hoặc mở app đang test. Ví dụ:

• Với website: bước 1 là “Mở https://test.io/”
• Với mobile app: bước 1 là “Mở app testNow”

Các bước tiếp theo mô tả hành động thực hiện từ đầu cho tới lúc lỗi xảy ra: bấm nút gì, theo link nào, nhập gì. Bước cuối cùng phải là hành động trực tiếp gây ra lỗi.

Hãy viết các bước càng tổng quát càng tốt. Chỉ nêu điều kiện cụ thể (một trang sản phẩm nhất định, một bộ lọc nhất định…) khi lỗi chỉ xảy ra đúng trong điều kiện đó. Nếu lỗi xảy ra với mọi sản phẩm, không cần chỉ đích danh một sản phẩm nào.

Ví dụ các bước tốt

1. Truy cập http://www.examplewebsite.com
2. Nhập bất kỳ từ khoá nào vào ô tìm kiếm ở góc phải trên (ví dụ “San Francisco”)
3. Bấm nút “Search Now”
4. Cuộn xuống và bấm “Sort by”
5. Chọn “Sort by price: High to Low”

6. Kết quả thực tế (Actual Result)

Đây là trường quan trọng nhất trong cả báo cáo, vì nó giải thích vấn đề thật sự là gì. Hãy mô tả chi tiết những gì xảy ra sau khi làm theo các bước, kèm ví dụ cụ thể thay vì nói chung chung.

Ví dụ Actual Result

Đúng	Sai
“Error 500 - Internal Server error - Sorry something went wrong” hiện ra khi người dùng cố chuyển tới trang Checkout.	Lỗi hiện ở trang Cart sau khi bấm nút Checkout.
Thông báo “Unexpected Error” hiện ở góc trên bên phải trang sản phẩm, sản phẩm không được thêm vào giỏ.	Người dùng không thể thêm sản phẩm vào giỏ, có lỗi hiện ra.

7. Kết quả kỳ vọng (Expected Result)

Hãy mô tả điều đáng lẽ phải xảy ra sau bước cuối cùng, tức là hệ thống lẽ ra phải hoạt động thế nào nếu không có lỗi.

Ví dụ Expected Result

Đúng	Sai
Trang Checkout phải được tải thành công.	Người dùng phải được chuyển đúng tới trang Checkout, nơi có thể nhập thông tin giao hàng, thanh toán và đặt hàng.
Sản phẩm “Batman T-Shirt” phải được thêm vào giỏ để người dùng tiếp tục đặt hàng.	Sản phẩm “Batman T-Shirt” phải được thêm thành công vào giỏ, người dùng không gặp lỗi như “Error 500” và có thể thanh toán mọi sản phẩm trong giỏ.

8. Tệp đính kèm (Attachments)

Cần đính kèm ảnh hoặc video minh hoạ trực quan cho lỗi, đúng theo quy định về loại tệp đính kèm hợp lệ.

9. Môi trường sử dụng (Used Environment)

Cần cho biết chính xác thiết bị đã dùng để phát hiện lỗi. Với website, chọn đúng biểu tượng trình duyệt cạnh thiết bị đã dùng. Với mobile app, chọn đúng thiết bị đã cài app để test.

Mỗi báo cáo chỉ được chọn một thiết bị hoặc trình duyệt, và chỉ đính kèm tệp cho đúng thiết bị đó. Nếu lỗi cũng tái hiện được trên thiết bị hoặc trình duyệt khác, hãy ghi chú thêm trong Actual Result.

10. Cải thiện báo cáo

Sau khi gửi, bạn vẫn có thể chỉnh sửa mọi trường trừ loại bug đã chọn. Chỉ nên dùng chức năng Edit (chỉnh sửa) để sửa lỗi chính tả nhỏ hoặc diễn đạt lại cho rõ hơn, không được gửi một báo cáo còn thiếu rồi tính sửa sau.

Nếu lỗi chỉ xảy ra với một dữ liệu đầu vào cụ thể, hãy dùng dữ liệu giống với những gì người dùng thật sẽ nhập, tránh gõ chuỗi ký tự ngẫu nhiên như “asdsdfkg_lajsdh” vì sẽ làm báo cáo trông thiếu chuyên nghiệp.

Bạn có thể xoá một báo cáo gửi nhầm, nhưng chỉ khi báo cáo đó chưa được Team Leader review.

Trắc nghiệm: Yêu cầu Báo cáo Lỗi · 5 câu · 8 phút