Cách viết bug report chuyên nghiệp: Mô tả, mức độ nghiêm trọng và bước tái hiện

3 ngày trước · 11 phút đọc

Bug report tệ tốn thời gian của cả team

Mình nhớ hồi mới đi làm, viết bug report kiểu: "Màn hình đăng nhập bị lỗi. Please fix." Dev quay lại hỏi: lỗi ở đâu? lỗi lúc nào? làm sao tái hiện? Mình mất thêm 30 phút giải thích. Dev mất thêm 1 tiếng reproduce. Bug fix xong lại sai chỗ vì mình mô tả nhầm.

Một bug report tệ không phải chỉ khó chịu - nó làm cả sprint chậm lại.

Bug report tốt giúp dev hiểu ngay vấn đề là gì, xảy ra ở đâu, làm thế nào để thấy lại lỗi đó. Không cần hỏi thêm, không cần họp giải thích. Fix xong đúng chỗ, đúng lần đầu.

Bài này mình đi qua từng phần của một bug report chuẩn, cách chọn severity (mức độ nghiêm trọng) cho đúng, và những lỗi fresher hay mắc nhất. Cuối bài có template và checklist để bạn dùng ngay.

347223 Bug report rõ ràng giúp dev fix đúng ngay lần đầu, không cần họp thêm

Cấu trúc một bug report đầy đủ

Một bug report chuẩn gồm 8 phần. Mình giải thích từng phần để bạn hiểu tại sao cần, không chỉ biết điền gì.

1. Title (tiêu đề)

Viết theo công thức: [Màn hình/Chức năng] + [Hành động] + [Kết quả sai]

❌ Tệ: "Lỗi đăng nhập"
✅ Tốt: "Trang đăng nhập - Nhập password có ký tự đặc biệt (@#$) - Hệ thống báo sai password dù thông tin đúng"

Title rõ giúp dev nhìn vào biết ngay bug ở đâu mà không cần đọc hết.

2. Description (mô tả tổng quan)

Tóm tắt 2-3 câu: bug là gì, xảy ra trong tình huống nào. Không cần dài, cần đủ để người chưa biết gì hiểu bức tranh tổng.

3. Steps to reproduce (bước tái hiện)

Đây là phần quan trọng nhất. Dev cần follow đúng steps để thấy lại bug. Viết số thứ tự, mỗi bước là 1 hành động cụ thể.

1. Mở trình duyệt Chrome, truy cập https://demo.com/login
2. Nhập email: [email protected]
3. Nhập password: P@ssw0rd#123
4. Click nút "Đăng nhập"
5. Quan sát kết quả

Bước không rõ = dev không reproduce được = bug không được fix.

4. Expected result (kết quả mong đợi)

Nếu không có bug, điều gì phải xảy ra? Ví dụ: "Hệ thống đăng nhập thành công, chuyển hướng về trang dashboard."

5. Actual result (kết quả thực tế)

Bug thực sự xảy ra điều gì? Ví dụ: "Hệ thống hiển thị thông báo 'Sai email hoặc mật khẩu' dù thông tin nhập đúng."

Ghi chính xác nội dung thông báo lỗi nếu có - copy y chang, đừng paraphrase.

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

Mình giải thích chi tiết phần này ở section sau.

7. Priority (ưu tiên xử lý)

Khác với severity - mình cũng làm rõ bên dưới.

8. Attachment (đính kèm)

Screenshot hoặc video màn hình. Không có attachment = bug report thiếu bằng chứng.

347224 8 phần của bug report - thiếu bất kỳ phần nào đều có thể làm dev hiểu sai

Severity và Priority: hai thứ khác nhau mà fresher hay nhầm

Đây là điểm mình thấy fresher mắc nhiều nhất. Severity và Priority nghe có vẻ giống nhau nhưng thực ra khác hoàn toàn.

Severity = mức độ bug ảnh hưởng đến hệ thống (do tester đánh giá dựa trên technical impact)

Priority = bug cần fix nhanh đến đâu trong sprint (do team/PM quyết định dựa trên business)

Ví dụ: Button "Chia sẻ lên Facebook" bị lỗi. Về mặt kỹ thuật, tính năng này bị break hoàn toàn (severity: High). Nhưng sản phẩm đang trong giai đoạn launch lớn, tính năng này ít người dùng nên team quyết định fix sau sprint này (priority: Low).

Bug severity cao không nhất thiết có priority cao. Hai thứ này độc lập nhau.

Cách chọn Severity

Severity	Khi nào dùng	Ví dụ
Critical	Hệ thống crash, dữ liệu mất, không workaround	Thanh toán xong bị trừ tiền nhưng không tạo đơn hàng
High	Tính năng chính không hoạt động, có workaround tạm	Không đăng nhập được bằng email, nhưng đăng nhập Google vẫn ok
Medium	Tính năng phụ bị lỗi, UX ảnh hưởng nhưng không block	Nút filter không hoạt động trên mobile
Low	Lỗi giao diện nhỏ, typo, không ảnh hưởng functionality	Button bị lệch 5px so với design

Quy tắc đơn giản để nhớ: hỏi "Nếu bug này không fix, user có bị block khỏi tính năng chính không?" Có = High/Critical. Không = Medium/Low.

347225 Severity và Priority độc lập nhau - đừng để nhầm làm sai trọng tâm fix bug

Về Priority thì thường team sẽ cùng quyết định trong planning. Tester đề xuất, PM và dev cùng confirm. Bạn không cần tự set priority một mình - nhưng cần hiểu logic để contribute vào discussion.

Cách viết steps to reproduce thật sự chi tiết

Mình sẽ thẳng thắn: đây là phần mà 80% fresher viết tệ nhất.

Steps to reproduce tệ thường trông như thế này:

1. Vào trang web
2. Thử đăng nhập
3. Bị lỗi

Dev đọc vào không biết: vào bằng trình duyệt gì? URL chính xác là gì? Dữ liệu test dùng gì? Nhấn nút hay dùng Enter?

Nguyên tắc viết steps chuẩn

1 bước = 1 hành động duy nhất. Không gộp nhiều hành động vào 1 bước.

❌ "Nhập thông tin và click đăng nhập"
✅ Bước 3: Nhập email [email protected] vào ô Email / Bước 4: Nhập password Pass@1234 vào ô Password / Bước 5: Click nút "Đăng nhập"

Ghi rõ data test. Không viết "nhập email" mà phải viết email cụ thể bạn dùng. Không viết "chọn sản phẩm" mà ghi tên sản phẩm bạn chọn.

Ghi precondition (điều kiện trước) nếu có. Ví dụ: "Tài khoản phải đã được verify email" hoặc "User phải đang ở trạng thái chưa đăng nhập".

Ghi môi trường test. Trình duyệt + phiên bản, OS, device (nếu mobile). Bug có thể chỉ xảy ra trên Chrome 120 mà không xảy ra trên Safari.

347226 Steps càng cụ thể, dev reproduce càng nhanh - tiết kiệm thời gian cho cả team

Ví dụ steps chuẩn so với steps tệ

❌ Steps tệ:

1. Đăng nhập vào hệ thống
2. Thêm sản phẩm vào giỏ hàng
3. Thanh toán bị lỗi

✅ Steps chuẩn:

Precondition: Tài khoản [email protected] đã có sẵn trong hệ thống, chưa đăng nhập.
Môi trường: Chrome 120, Windows 11, màn hình desktop 1920x1080

1. Mở Chrome, truy cập https://demo-shop.com
2. Click "Đăng nhập" ở góc trên phải
3. Nhập email: [email protected]
4. Nhập password: Demo@1234
5. Click nút "Đăng nhập" màu xanh
6. Tìm kiếm sản phẩm "Áo thun trắng size M" trong ô Search
7. Click vào sản phẩm đầu tiên trong kết quả
8. Click "Thêm vào giỏ hàng"
9. Click icon giỏ hàng ở góc trên phải
10. Click "Thanh toán ngay"

Expected: Chuyển đến trang nhập địa chỉ giao hàng
Actual: Trang trắng xuất hiện, URL thay đổi thành /checkout/error

Nhìn vào sự khác biệt là rõ. Steps chuẩn không cần giải thích thêm, dev follow từng bước là reproduce được ngay.

Chụp screenshot và quay video đúng cách

Attachment không phải "đính kèm cho có". Một screenshot tốt đôi khi nói được nhiều hơn 10 bước mô tả.

Screenshot cần gì?

Chụp cả màn hình, không crop quá hẹp. Dev cần thấy context xung quanh, không chỉ vùng lỗi. URL trên thanh địa chỉ cũng cần hiện - đó là bằng chứng bạn đang test đúng trang.

Đánh dấu vùng lỗi. Dùng tool chụp màn hình có annotation (Windows Snipping Tool, Lightshot, hoặc Jira screenshot) để khoanh đỏ hoặc mũi tên chỉ đúng chỗ bug. Dev không phải tự đoán bạn muốn chỉ vào đâu.

Screenshot trước VÀ sau. Ví dụ: chụp form trước khi submit (data đã nhập), và chụp màn hình sau khi submit (thông báo lỗi hiện ra).

Khi nào cần quay video?

Bug có animation, timing, hoặc xảy ra trong quá trình transition giữa các trang thì screenshot không đủ. Quay video ngắn 30-60 giây để capture toàn bộ flow.

Tool gợi ý: Loom (free, record và share link ngay) hoặc OBS nếu cần chất lượng cao hơn.

347227 Screenshot có annotation giúp dev nhìn thấy bug ngay, không cần đoán

Một lưu ý quan trọng: không chụp screenshot ảnh nhạy cảm. Nếu bug xảy ra trên màn hình có data thật của user (tên, số điện thoại, email thật), blur hoặc crop phần đó trước khi attach vào Jira. Đây là thói quen bảo mật cần có ngay từ đầu.

5 lỗi fresher hay mắc khi viết bug report

Mình tổng hợp từ việc review bug report của nhiều bạn mới vào nghề. Những lỗi này không phải do lười - chủ yếu do chưa biết tại sao phải làm kỹ.

Lỗi 1: Title chung chung "Lỗi trang thanh toán" - dev có 50 bug về trang thanh toán, không biết đây là cái nào. Fix: dùng công thức [Màn hình] + [Hành động] + [Kết quả sai].

Lỗi 2: Quên steps to reproduce Viết description rất dài nhưng không có steps. Dev đọc xong vẫn không biết làm sao để thấy bug. Fix: steps là phần bắt buộc, không có exception.

Lỗi 3: Không có evidence Mô tả bug nhưng không screenshot, không log lỗi. Nếu dev không reproduce được (ví dụ bug flaky - lúc có lúc không), không có evidence thì bug đó gần như không tồn tại về mặt chứng minh. Fix: luôn attach tối thiểu 1 screenshot.

Lỗi 4: Nhầm severity Coi mọi bug là Critical hoặc High. Khi mọi thứ đều urgent thì không có gì thực sự urgent. Đội dev mất khả năng prioritize. Fix: dùng bảng severity ở trên, hỏi "tính năng chính có bị block không?" để phân loại.

Lỗi 5: Không verify lại trước khi submit Viết xong submit luôn. Mình từng submit bug mà steps thiếu bước 3, dev hỏi lại mới phát hiện. Mất thêm 1 ngày. Fix: đọc lại bug report 1 lần theo đúng góc nhìn của người chưa biết gì, tự hỏi "đọc cái này, mình có reproduce được không?"

347228 5 lỗi này có thể tránh hoàn toàn nếu dành thêm 5 phút review trước khi submit

Thấy khó ở phần severity hay steps? Bình thường - mình cũng mất khoảng 2-3 tuần thực hành mới viết tự nhiên. Quan trọng là bắt đầu viết, rồi nhờ senior review và điều chỉnh dần.