Tiếp nhận bug phần mềm có thể tái hiện
Biểu mẫu báo cáo bug cho vấn đề phần mềm có thể tái hiện
Hướng dẫn người báo cáo cung cấp thành phần và build bị ảnh hưởng, bối cảnh chạy, đường tái hiện ngắn nhất, kết quả kỳ vọng, kết quả thực tế và bằng chứng mà không yêu cầu họ đoán mức ưu tiên hoặc giao người sửa.
Đăng nhập để kiểm tra chế độ xem đã có dữ liệu này, rồi cài App với dữ liệu mẫu để kiểm thử bản ghi, quyết định và bảng tổng quan được liên kết.
Người báo cáo cung cấp gì và đội phân loại quyết định gì
Một biểu mẫu báo cáo bug tốt tăng khả năng người khác tái hiện được vấn đề. Biểu mẫu nên thu thập dữ kiện quan sát được trước, rồi để đội phân loại quyết định mức độ nghiêm trọng, mức ưu tiên, người phụ trách và phiên bản phát hành mục tiêu.
- Trường của người báo cáo tách khỏi trường phân loại
- Biểu mẫu an toàn cho di động với bằng chứng dạng tệp
- Luồng trả lại để bổ sung thông tin thay vì từ chối âm thầm
Hướng dẫn trường cho người báo cáo
Thu thập gói tái hiện tối thiểu nhưng đầy đủ
Mỗi trường nên giúp ai đó lặp lại, phân loại hoặc điều tra vấn đề.
- 01
Tóm tắt rõ ràng
Mô tả lỗi nhìn thấy và thao tác bị ảnh hưởng.
- 02
Thành phần và build
Chọn phạm vi sản phẩm và phiên bản chính xác khi biết.
- 03
Môi trường
Ghi lại thiết bị, trình duyệt, hệ điều hành, tenant hoặc cấu hình.
- 04
Bước tái hiện
Liệt kê chuỗi ngắn nhất có thể lặp lại theo đúng thứ tự.
- 05
Kỳ vọng so với thực tế
Nêu riêng kết quả mong muốn và điều đã xảy ra.
- 06
Bằng chứng và tác động
Đính kèm bằng chứng hữu ích và giải thích ai không thể tiếp tục.
Sau khi gửi
Trả lại báo cáo chưa đủ thông tin mà không làm mất cuộc trao đổi
Biểu mẫu chỉ là bước khởi đầu; đội phân loại cần bước kế tiếp rõ ràng cho từng kết quả.
Kiểm tra khả năng tái hiện
Xác nhận môi trường và lặp lại đường đi đã cung cấp.
Yêu cầu bối cảnh còn thiếu
Trả báo cáo kèm câu hỏi cụ thể và giữ nguyên cùng bản ghi.
Gộp bản trùng lặp
Liên kết báo cáo mới với vấn đề chuẩn thay vì xóa nó.
Chấp nhận và giao phụ trách
Ghi lại mức độ nghiêm trọng, mức ưu tiên, người phụ trách và phiên bản phát hành mục tiêu.
Viết báo cáo mà người khác có thể hành động
Thay tuyên bố mơ hồ bằng khác biệt quan sát được
Một báo cáo ngắn vẫn có thể đầy đủ khi tách bối cảnh, hành động và kết quả.
| Báo cáo yếu | Báo cáo có thể xử lý | Vì sao tốt hơn |
|---|---|---|
| Checkout bị lỗi | Xác nhận thanh toán hết thời gian chờ sau khi quay lại từ 3DS trong Web 4.28.0 | Nêu rõ hành động, lỗi và build. |
| Đồng bộ bị trùng | Chạm đồng bộ hai lần sau khi kết nối lại tạo hai dòng có cùng ID cục bộ | Cung cấp tác nhân kích hoạt có thể lặp lại và kết quả quan sát được. |
| Xuất sai | CSV theo lịch bỏ sót hai cột tùy chỉnh đã lưu trong Reporting 12.2 | Xác định chế độ, khác biệt dữ liệu và phiên bản phát hành. |
Câu hỏi và ranh giới
Câu hỏi về biểu mẫu báo cáo bug
Câu trả lời để quyết định trường nào thuộc tiếp nhận và trường nào thuộc phân loại.
Người báo cáo có nên chọn mức độ nghiêm trọng và mức ưu tiên không?
Thường là không. Người báo cáo có thể mô tả tác động kinh doanh và mức khẩn cấp, còn đội phân loại áp dụng định nghĩa chung về mức độ nghiêm trọng và mức ưu tiên.
Bước tái hiện nên dài đến đâu?
Dùng chuỗi ngắn nhất mà người khác có thể lặp lại. Chỉ đưa phần thiết lập khi nó làm thay đổi kết quả, và ghi chú tần suất xảy ra nếu hành vi không liên tục.
Nếu người báo cáo không biết build thì sao?
Cho phép “chưa biết”, nhưng thu thập đủ bối cảnh môi trường để đội phân loại xác định. Đừng chặn báo cáo hữu ích chỉ vì thiếu một trường kỹ thuật.
Biểu mẫu có dùng được trên di động không?
Có. Người báo cáo có thể ghi lại thành phần bị ảnh hưởng, môi trường, các bước tái hiện và bằng chứng trên điện thoại, rồi gửi vào cùng hàng đợi phân loại như người dùng máy tính.
Cải thiện lần bàn giao đầu tiên
Bắt đầu với một báo cáo mà người khác có thể tái hiện
Mở biểu mẫu mẫu trên desktop hoặc di động, rồi điều chỉnh trường dữ liệu và định tuyến theo sản phẩm của bạn.