Thời gian vừa rồi mình có review một số phản hồi mà QC/BA báo cho anh em Dev, có nhiều bug, issue mà đội này báo cáo, nội dung thật là ngắn gọn: “Upload file bị lỗi”, “Không đăng nhập được”, “App bị lỗi”,…
Không screenshot, không steps to reproduce, không nói lỗi ở màn hình nào, môi trường nào. Chấm hết.
Và rồi từ những thông tin mù mờ như vậy, mình hít một hơi thật sâu, rồi nhắn lại: “Anh chị ơi, lỗi là gì, ở đâu, api nào bị lỗi, làm gì thì bị?” Đợi 1 tiếng sau mới được reply: “Ơ, em cũng không nhớ nữa, để em thử lại.”
Chết thật.
Nếu anh em là kỹ sư phần mềm, chắc ai cũng từng nhận những bug report kiểu này ít nhất một lần trong đời, đúng không? Và nếu anh chị là người hay báo bug, có thể là tester, QC, PM, hoặc những ai làm trong ngành phần mềm thì bài viết này mình viết cho mọi người đấy.
Theo thống kê từ các dự án open-source lớn, 27% bug report bị reject hoặc bị đánh dấu “works for me”, đa phần không phải vì bug không tồn tại, mà vì người báo không cung cấp đủ thông tin để dev reproduce được. Nghĩa là gần 1/3 công sức báo bug bị lãng phí vì cách viết.
Bài này mình viết từ góc nhìn của một kỹ sư, người ở tuyến đầu nhận bug report mỗi ngày. Không phải để kêu ca, mà để mọi người hiểu rằng nếu báo bug có tâm một chút, có thể tiết kiệm rất nhiều thời gian cho cả hai bên.
Mục Lục
“App bị lỗi” và dev phải tự suy luận như thám tử
Mình làm phần mềm cũng kha khá năm, và nếu phải liệt kê những kiểu bug report khiến mình muốn úp mặt vào bàn phím thì chắc kể cả ngày không hết. Nhưng gom lại thì có mấy kiểu “kinh điển” sau:
Kiểu 1: “App bị lỗi rồi”
Đây là kiểu phổ biến nhất. Tin nhắn gửi qua chat hoặc Jira chỉ có đúng một dòng: “App bị lỗi” hoặc “Chức năng X không chạy”.
Không thêm bất kỳ thông tin gì. Dev nhận được thì kiểu: lỗi gì, ở đâu, làm gì thì bị, môi trường nào? Chúng tôi là developer chứ không phải nhà ngoại cảm.
Kiểu 2: “Hôm qua vừa chạy được mà”
Kiểu này nghe có vẻ hữu ích nhưng thực ra chẳng có value gì cả. Hôm qua chạy được, oke, nhưng hôm qua bạn dùng data gì, thao tác ra sao, trên version app nào, tài khoản thực hiện có gì đặc biệt? Và hôm nay bạn làm khác gì so với hôm qua? Tất cả đều là ẩn số. Dev lại phải đi hỏi từng cái một, mỗi câu hỏi đợi nửa tiếng mới được trả lời.
Kiểu 3: Screenshot chụp cả màn hình, khoanh đỏ chỗ không liên quan
Mình từng thấy kiểu screenshot chụp full màn hình 27 inch, khoanh tròn đỏ một cái nút, nhưng lỗi thực tế lại ở response API dưới backend mà screenshot không thấy. Hoặc tệ hơn là screenshot chụp bằng điện thoại, chụp lại màn hình máy tính, mờ tịt, nghiêng 45 độ. Nhìn mà thấy thương cho người chụp màn hình.
Kiểu 4: “Chắc do code sai”
Kiểu này hơi nhạy cảm, người báo bug không chỉ mô tả hiện tượng mà còn kết luận luôn nguyên nhân: “Chắc do anh code sai đoạn xử lý payment”, “Sao lại vô tình đúng lúc bạn đẩy code lên thế”.
Vấn đề là 8/10 lần cái kết luận đó sai, nhưng nó tạo ra một tâm lý phòng thủ cho mấy ông dev ngay từ đầu. Thay vì cùng nhau tìm lỗi, cuộc hội thoại biến thành tranh luận ai đúng ai sai.
Chung quy lại, tất cả các kiểu trên đều có chung một vấn đề: thiếu rất nhiều thông tin. Và khi thiếu thông tin thì dev phải biến thành thám tử: đi hỏi, đi đoán, đi reproduce, mất hàng tiếng đồng hồ trước khi thực sự bắt đầu công nhận đó là bug và đi fix bug.
Bug report từ thiên đường trông như thế nào?
Nói xong mấy kiểu “địa ngục” rồi, giờ mình lấy ví dụ ngược lại, cùng một con bug, nhưng hai cách báo khác nhau thì dev tiếp nhận ra sao.
Giả sử có bug: API upload ảnh CMND trả lỗi 500.
Bản “Địa Ngục“:
“Upload ảnh bị lỗi rồi anh ơi”
Dev nhận được cái này thì sẽ phải hỏi lại: lỗi upload ở đâu, upload ở màn nào, ảnh gì, trên môi trường nào, file dung lượng gửi lên bao nhiêu mb, định dạng upload lên là gì?
Mỗi câu hỏi đợi reply, rất mất thời gian để hiểu điều gì đang xảy ra. Rồi sau khi hỏi xong, dev phải tự đi reproduce, mất thêm thời gian nữa.
Bản “Thiên Đường“:
Tiêu đề: API upload ảnh CMND trả lỗi 500 trên môi trường UAT
Môi trường: UAT — Android 13, app version 2.4.1
Steps to reproduce:
1. Đăng nhập tài khoản ví có số: 0901xxx123
2. Vào màn hình eKYC → bước chụp CMND mặt trước
3. Chụp ảnh hoặc chọn ảnh từ thư viện (file PNG, ~3MB)
4. Bấm “Tiếp tục”Expected: Upload thành công, chuyển sang bước chụp mặt sau
Actual: Hiển thị lỗi “Có lỗi xảy ra”, API trả về HTTP 500
Screenshot: (ảnh chụp màn hình lỗi, khoanh đúng chỗ thông báo lỗi)
Ghi chú: Thử 3 lần đều bị. Thử file JPEG ~1MB thì upload được bình thường.
Anh em thấy sự khác biệt chưa?
Bản thiên đường cho dev biết ngay: lỗi ở API upload trên môi trường UAT chỉ xảy ra với file PNG ~3 MB, còn JPEG ~1 MB thì được. Dev đọc xong là biết luôn hướng check, có thể do giới hạn file size hoặc do xử lý định dạng PNG.
Dev fix được luôn trong 15 phút, không cần hỏi lại một câu nào.
Bản địa ngục thì sao? Mấy ông Dev mất cả tiếng đi hỏi, rồi mới bắt đầu reproduce, rồi mới bắt đầu fix. Cùng một con bug mà thời gian xử lý chênh nhau cả chục lần chỉ vì cách viết bug report.
Mình không đòi hỏi mọi người phải viết report dài 2 trang, nhưng sự khác biệt giữa “upload bị lỗi” và “upload file PNG 3MB trên UAT trả 500, JPEG 1MB thì OK” rất khác biệt, chỉ mất thêm 2 phút để viết, nhưng sẽ tiết kiệm cho cả team hàng tiếng đồng hồ.
5 thứ cần có trong mọi bug report
Qua mấy năm nhận đủ kiểu bug report, mình rút ra được một công thức khá đơn giản. Mọi người không cần viết dài làm gì, chỉ cần đảm bảo 5 thứ này là dev thầm cảm ơn các bạn:
1. Tiêu đề rõ ràng — What + Where + When
Đừng viết "Lỗi app", "App không đăng nhập được", mà thay vào đó hãy viết “API upload ảnh CMND trả 500 trên UAT”.
Dev nhìn nhanh qua danh sách 50 ticket là có thể hiểu ngay vấn đề từ tiêu đề luôn, không cần click vào đọc.
2. Steps to reproduce — Đánh số, bắt đầu từ trạng thái ban đầu
Viết kiểu numbered list, bắt đầu từ bước đầu tiên. Đừng giả định dev biết bạn đang ở màn hình nào. VD:
1. Đăng nhập vào tài khoản ví của số điện thoại: 0901xxx123 (có password trên môi trường phát triển càng tốt, ví dụ DEV, UAT)
2. Vào menu → vào luồng eKYC → Chụp CMND mặt trước
3. Chọn ảnh PNG ~3MB từ thư viện
4. Bấm "Tiếp tục"
3. Expected vs Actual — Tôi mong gì, thực tế ra gì
Đây là phần nhiều người hay bỏ qua nhất nhưng lại quan trọng nhất. Vì đôi khi cái mọi người nghĩ là “lỗi” thì dev lại nghĩ là “đúng rồi, design thế mà”. Nếu ghi rõ ra thì hai bên sẽ khỏi phải cãi nhau.
4. Môi trường — Environment
Dev, Uat, Staging, hay Production? Bản app cá nhân hay doanh nghiệp? iOS hay Android? App version nào? Nhiều khi bug chỉ xảy ra trên một môi trường cụ thể, nếu không ghi thì dev test trên local thấy chạy ngon lành, rồi chẳng có phản hồi gì tiếp theo cả.
5. Screenshot/Video — Khoanh đúng chỗ
Một tấm screenshot khoanh đúng chỗ lỗi đáng giá hơn ngàn chữ. Nếu bug liên quan đến flow nhiều bước, quay video ngắn 30 giây còn tốt hơn nữa. Nhưng nhớ là: khoanh đúng chỗ, đừng chụp cả màn hình rồi bắt dev tự tìm.
Bonus: Nếu mọi người đã thử những phương án để workaround gì (clear cache, đổi browser, đổi tài khoản test) thì ghi thêm vào nhé. Thông tin này giúp anh em dev loại trừ nguyên nhân cực nhanh.
Nghe có vẻ nhiều, nhưng thực tế, viết một bug report đầy đủ 5 thứ trên chỉ mất 3-5 phút.
Và theo thống kê, những team áp dụng template chuẩn thì thời gian xử lý bug trung bình giảm từ vài ngày xuống còn vài giờ, tỷ lệ bug bị reopen giảm từ 15-20% xuống dưới 3% (tỉ lệ mình chém gió thôi, nhưng hãy tin là nó có tác động rất lớn).
3 phút viết report cẩn thận, đổi lại cả team tiết kiệm hàng giờ. Deal quá hời mà trời.
Nhưng dev cũng cần tự nhìn lại mình
Nói thẳng luôn: không phải lúc nào lỗi cũng ở phía người báo bug.
Mình từng thấy nhiều dev có mấy thói quen cũng tệ không kém. Nhận bug report thì phản ứng đầu tiên là: “Works on my machine”, “Không reproduce được”, “Em không biết”, hoặc kinh điển nhất là “It’s not a bug, it’s a feature”. Dismiss xong rồi close ticket, không reply, không giải thích.
Mọi người cứ thử đứng ở vai trò của QC mà nghĩ xem: nếu mình là tester, bỏ công viết bug report cẩn thận, gửi đi rồi bị dev close mà không nói một lời nào, lần sau mình có muốn viết cẩn thận nữa không?
Dần dần, bug report ngày càng qua loa, rồi dev lại kêu “bug report gì mà chẳng có thông tin gì, em không muốn làm việc với chị”. Vòng lặp tiêu cực cứ thế lặp đi lặp lại không lối thoát.
Thực ra, gốc rễ của chuyện dev-tester hay xung đột không phải vì ai ghét ai cả, mà vì hai bên có mục tiêu khác nhau: dev chịu áp lực ship feature nhanh, tester chịu áp lực đảm bảo chất lượng.
Hai áp lực đó đụng nhau là có drama. Nhưng nếu cùng nhau nhìn lại một chút, mọi người sẽ thấy cả hai đều đang cố làm cho sản phẩm tốt hơn, chỉ là từ hai góc nhìn khác nhau thôi.
Nên mình nghĩ anh em dev cũng cần phải làm vài thứ:
- Acknowledge bug report: dù chưa fix được ngay thì ít nhất reply: “Tôi nhận thông tin rồi, sẽ kiểm tra và phản hồi lại”, trong trường hợp đó liên quan đến team của mình, nếu không phải mình làm thì cần assign đúng người chứ đừng để ticket treo im lìm.
- Hỏi thêm thay vì reject: thiếu thông tin thì hỏi, đừng close luôn. “Bạn test trên môi trường nào?” sẽ tốt hơn nhiều so với “Cannot reproduce, closed”.
- Cảm ơn người báo bug kỹ: nghe hơi sến sẩm nhưng mà thật, một câu “Cảm ơn em nhé, report rõ quá, anh tìm ra lỗi luôn” sẽ khiến lần sau người ta còn muốn viết kỹ hơn nữa.
Mình từng viết bài về chuyện lắng nghe trong công việc, và việc nhận bug report cũng là một dạng lắng nghe. Nghe để hiểu, không phải nghe để phản bác.
Quay lại câu chuyện đầu bài, cái ticket “App bị lỗi“, “Không đăng nhập được“, đó cuối cùng thì cũng sẽ fix được.
Nhưng thay vì mất 15 phút, mấy ông dev sẽ mất gần nửa ngày chỉ vì phải đi hỏi, đi đoán, đi reproduce từ con số 0.
Nửa ngày đó, các bạn có thể dùng để code feature mới hoặc đơn giản là về nhà sớm hơn một chút.
Ở cương vị kỹ sư, mỗi khi mình báo bug cho team khác hay cho bên thứ ba, mình luôn cố gắng viết đầy đủ bối cảnh nhất có thể, vì mình hiểu cảm giác ngồi nhận một cái ticket mà không biết bắt đầu từ đâu nó khổ như thế nào. Mình mong mọi người cũng hiểu điều đó.
Cuối cùng thì dev hay tester cũng đều đang ngồi chung một con thuyền, cùng cố làm cho sản phẩm tốt hơn mỗi ngày. Bug report chỉ là cách mình nói chuyện với nhau thôi, mà đã nói chuyện thì nói cho đàng hoàng, cho người ta lắng nghe được, phải không?
Nên lần tới, trước khi gửi báo bug, mọi người thử đặt mình vào vị trí người nhận. Chỉ cần vậy thôi, mọi thứ sẽ khác đi rất nhiều.
Hiện tại mình có đẩy các bài viết lên trên Medium và Substack. Các bạn quan tâm có thể chia sẻ cho bạn bè, nhấn follow, subscribe, hoặc đơn giản chỉ cần bấm thả tim, vỗ tay thôi là mình có động lực viết những bài viết mới rồi. Mình xin cảm ơn.
Xem thêm các bài viết nổi bật bên dưới:
- Tôi đã xoá hơn 3 triệu ảnh rác từ hệ thống legacy
- Xác thực giao dịch trong hệ thống tài chính
- Đồng nghiệp tôi vừa mới Golive và bùm, race condition
- Tổng hợp dữ liệu cho 1 triệu tài khoản trong 4 phút
- Xử lý lỗi lệch múi giờ khi dùng Mapstruct
- Có CodeRabbit làm tôi review code cũng nhàn hơn
- Lỗi trên môi trường Staging mà không ai chịu sửa đến cùng
- Filter Spring và pha xử lý bug nhớ đời
- Những thói quen tốt trong ngành phát triển phần mềm
- Rest API: Cách Ngăn Chặn Duplicate Request Hiệu Quả
- Sức mạnh của AI CLI – trợ thủ đắc lực cho dân lập trình
- Những điều khó đỡ trong ngành phần mềm #1
- “Bàn lùi” – hay là tư duy trách nhiệm bị hiểu nhầm?
