Viết bug report thế nào để Dev không trả về câu "máy tôi chạy bình thường"

Báo cáo là nhóm việc cuối trong bốn nhóm việc của một tester — ba nhóm trước ở Manual testing là gì.

"Máy tôi chạy bình thường."

Ai làm tester cũng nhận câu này. Và điều khó chịu nhất là phần lớn những lần đó, lỗi có thật — chỉ là bug report không đủ để người khác thấy nó.

Bài này là bảy phần của một bug report không bị trả về, cộng cách xử lý tình huống khó nhất: lỗi thấy một lần rồi không tái hiện được.

Một bug report tốt làm được đúng một việc

Người đọc tái hiện được lỗi trên máy của họ, không cần hỏi lại bạn câu nào.

Mọi quy tắc còn lại chỉ là cách đạt được câu trên.

Lỗi bị trả về gần như luôn vì một trong ba thứ: thiếu bước, thiếu thông tin môi trường, hoặc thiếu dữ liệu cụ thể. Ba thứ đó đều nằm trong tầm kiểm soát của người viết.

Bảy phần

1. Tiêu đề — nói được lỗi gì, ở đâu, trong một dòng.

❌ Lỗi giỏ hàng ✅ Giỏ hàng: xoá sản phẩm cuối cùng thì tổng tiền vẫn giữ giá cũ

Tiêu đề là thứ duy nhất được đọc khi có hàng trăm lỗi trong danh sách. Nó quyết định lỗi được xếp vào đâu và được xem lúc nào. Một tiêu đề mơ hồ khiến lỗi nặng bị xếp sau lỗi nhẹ, ngay từ đầu.

Công thức dùng được: chỗ nào — làm gì — kết quả sai gì.

2. Môi trường.

Trình duyệt và phiên bản. Hệ điều hành. Thiết bị. Bản triển khai nào — môi trường kiểm thử, môi trường chuẩn bị phát hành, hay bản đang chạy thật.

Đây là phần bị bỏ nhiều nhất và cũng là nguyên nhân số một của câu "máy tôi chạy bình thường". Lập trình viên mở Chrome trên máy của họ, bạn tìm ra lỗi trên Safari của iPhone. Cả hai đều đang nói thật.

3. Điều kiện trước.

Trạng thái phải có trước bước 1. Tài khoản loại gì, quyền gì, đang có dữ liệu gì.

Một lỗi chỉ xảy ra với tài khoản chưa xác thực email mà không ghi điều kiện này thì không ai tái hiện được, dù các bước đúng hoàn toàn.

4. Các bước tái hiện.

Từng bước, mỗi bước một hành động, có giá trị cụ thể.

❌ Thêm vài sản phẩm rồi xoá đi
✅

1. Thêm sản phẩm A (mã SP-001), số lượng 1
2. Thêm sản phẩm B (mã SP-002), số lượng 2
3. Xoá sản phẩm B
4. Xoá sản phẩm A

Phép thử: đưa các bước cho người chưa biết lỗi này, để họ tự chạy mà không giải thích thêm. Họ dừng lại hỏi ở bước nào thì bước đó cần viết lại.

5. Kết quả mong đợi — và vì sao.

Điều đáng lẽ phải xảy ra, kèm căn cứ: mục nào trong tài liệu yêu cầu, hoặc hành vi ở bản trước.

Không có tài liệu thì nói rõ đây là suy luận của bạn. Chỗ này quan trọng hơn vẻ ngoài của nó: rất nhiều tranh cãi "đây có phải lỗi không" bắt nguồn từ việc không ai chỉ ra được cái đúng nằm ở đâu. Nêu căn cứ ngay từ đầu thì tranh cãi đó không xảy ra.

6. Kết quả thực tế.

Điều đã xảy ra. Chép nguyên văn thông báo lỗi nếu có — chép ra chữ, đừng chỉ mô tả lại. Nguyên văn thông báo là thứ lập trình viên tìm kiếm trong mã nguồn để lần ra chỗ sinh ra nó.

7. Bằng chứng.

Ảnh chụp màn hình. Video nếu lỗi liên quan tới thứ tự thao tác hoặc tới thời gian. Log nếu lấy được.

Ảnh chụp màn hình: hai chi tiết hay bị cắt mất

Một ảnh chụp đúng tiết kiệm cả một vòng hỏi đáp. Hai thứ thường bị crop mất, và cả hai đều quan trọng.

• Thanh địa chỉ: Nó cho biết bạn đang ở đúng bản triển khai nào và đúng trang nào. Cắt mất là mất luôn thông tin đó, và đó thường là thông tin quyết định.
• Giờ trên máy: Đối chiếu được với log ở phía máy chủ. Không có giờ thì việc tìm log tương ứng khó hơn nhiều.

Nếu lỗi liên quan tới dữ liệu, chụp cả phần dữ liệu chứ đừng chỉ chụp thông báo lỗi.

Lỗi không tái hiện được thì báo thế nào

Đây là tình huống khó nhất và hầu như không bài nào nói tới.

Bạn thấy lỗi một lần. Thử lại năm lần không ra. Bỏ đi thì sai — nó có thể là lỗi nặng nhất trong cả bản. Báo mà không có bước tái hiện thì bị đóng lại với trạng thái không tái hiện được.

Bốn việc nên làm.

• Ghi lại mọi thứ còn nhớ, ngay lập tức: Trước khi trí nhớ mờ. Thứ giá trị nhất là giờ chính xác, vì nó là đầu mối duy nhất để đối chiếu log.
• Nói thẳng trong report rằng chưa tái hiện được: Ghi rõ đã thử lại bao nhiêu lần. Che chuyện này đi thì mất uy tín khi lộ ra; nói thẳng thì report vẫn có giá trị như một manh mối được ghi nhận.
• Ghi cả những thứ trông như không liên quan: Đang mở bao nhiêu tab. Mạng có chập không. Vừa làm gì trước đó. Có ai khác đang sửa cùng dữ liệu đó không. Loại lỗi này thường do một tổ hợp điều kiện, và bạn không biết trước điều kiện nào là điều kiện quan trọng.
• Đừng đoán nguyên nhân như thể chắc chắn: Nếu có phỏng đoán, ghi rõ đó là phỏng đoán.

Một bug report tái hiện không được nhưng ghi đủ giờ và bối cảnh vẫn hữu ích. Nó sẽ được nối lại với lần thứ hai, và lúc đó hai manh mối cộng lại thành một lỗi tìm ra được.

Ba câu đừng viết

• "Chức năng này không hoạt động.": Không hoạt động thế nào? Trắng trang, báo lỗi, hay chạy nhưng ra kết quả sai? Ba trường hợp đó có ba nguyên nhân hoàn toàn khác nhau.
• "Chắc do cache.": Đoán nguyên nhân là việc của người sửa. Một phỏng đoán sai đặt trong report làm họ đi lệch hướng ngay từ đầu, và tốn thời gian nhiều hơn là không đoán gì. Nếu bạn có căn cứ thật thì nêu căn cứ, đừng nêu kết luận.
• "Lỗi này rất nghiêm trọng, sửa ngay.": Mức nghiêm trọng và mức ưu tiên là hai trường riêng, có định nghĩa rõ. Viết vào phần mô tả chỉ thành cảm tính, và làm ý kiến của bạn bị coi nhẹ dần.

Nói lại một câu

Tìm ra lỗi là nửa công việc. Nửa còn lại là viết lại nó sao cho công sức ở nửa đầu không mất trắng.

Trước khi bấm gửi, đọc lại report và tự hỏi: người này có cần hỏi tôi thêm gì không? Còn một câu thì thêm vào luôn.