Tìm ra lỗi mới là một nửa công việc của một Manual Tester — nửa còn lại là báo lỗi sao cho dev hiểu và chịu sửa. 🙂 Muốn vậy, bạn cần nắm bug life cycle (vòng đời của bug) và cách viết bug report chuẩn. Bài này tôi đi qua các trạng thái của một lỗi từ lúc sinh ra đến lúc đóng, các trường bắt buộc trong bug report, một ví dụ mẫu, và mẹo để bug của bạn không bị reject.

Bug life cycle là gì?

Bug life cycle (defect life cycle, vòng đời của bug) là chuỗi các trạng thái mà một lỗi đi qua kể từ khi được phát hiện cho tới khi được đóng. Vòng đời điển hình là: New → Assigned → Open → Fixed → Retest → Verified → Closed, kèm các nhánh rẽ như Reopened, Rejected, Duplicate hay Deferred tùy tình huống.

Hiểu vòng đời này giúp bạn biết một lỗi đang ở đâu, ai đang chịu trách nhiệm, và bước tiếp theo là gì. Luồng chuẩn nhất là: tester tạo lỗi (New), lỗi được gán cho dev (Assigned), dev sửa (Fixed), tester kiểm tra lại (Retest); nếu hết lỗi thì xác nhận và đóng (Verified → Closed), còn nếu vẫn lỗi thì mở lại (Reopened).

Các trạng thái của bug (New → Closed)

Dưới đây là các trạng thái phổ biến — tên cụ thể có thể khác đôi chút tùy công cụ và quy trình của từng đội:

Trạng thái Ý nghĩa Ai phụ trách
New Lỗi vừa được tester ghi nhận Tester
Assigned Lỗi được gán cho một dev xử lý Lead / Manager
Open / In Progress Dev đang phân tích và sửa Dev
Fixed Dev báo đã sửa xong Dev
Pending Retest Chờ tester kiểm tra lại bản đã sửa Tester
Verified Tester xác nhận lỗi đã được sửa đúng Tester
Reopened Lỗi vẫn còn sau khi sửa → mở lại Tester
Closed Lỗi đã được xử lý dứt điểm Tester
Rejected Bị từ chối (không phải lỗi / sai mô tả) Dev / Lead
Duplicate Trùng với một lỗi đã được báo trước đó Dev / Lead
Deferred Hoãn sửa sang phiên bản/đợt sau Lead / PM

Luồng rút gọn dễ nhớ: New → Assigned → Open → Fixed → Pending Retest → Verified → Closed. Khi retest thất bại, lỗi quay về Reopened → Open; còn Rejected/Duplicate/Deferred là các nhánh rẽ sớm ngay sau khi xem xét.

Cách viết bug report tốt (các trường bắt buộc)

Một bug report tốt phải đủ thông tin để dev tái hiện và sửa được mà không cần hỏi lại bạn. Theo nội dung defect report của ISTQB, các trường nên có gồm:

Trường Mô tả
Bug ID Mã định danh duy nhất
Title / Summary Tóm tắt lỗi trong một dòng, đọc là hiểu
Module / Chức năng Nơi xảy ra lỗi
Environment OS, trình duyệt/thiết bị, phiên bản build, môi trường
Severity Mức nghiêm trọng kỹ thuật của lỗi
Priority Mức ưu tiên cần sửa
Pre-condition Điều kiện cần có trước khi tái hiện
Steps to Reproduce Các bước tái hiện, đánh số, mỗi bước một hành động
Expected Result Kết quả mong đợi
Actual Result Kết quả thực tế quan sát được
Attachments Ảnh chụp, video, log minh chứng
Status Trạng thái hiện tại trong vòng đời
Reported by / Date Người báo lỗi và ngày báo
Assigned to Người được giao xử lý

Quan trọng nhất là cặp Expected vs Actual và Steps to Reproduce — đây là phần giúp dev hiểu "lẽ ra phải thế này, nhưng thực tế lại thế kia, và đây là cách thấy nó". Bug report và test case dùng chung tư duy mô tả rõ ràng — xem thêm cách viết test case.

Severity và Priority — đừng nhầm

Hai khái niệm này hay bị lẫn: Severity là mức nghiêm trọng về kỹ thuật (lỗi ảnh hưởng hệ thống nặng tới đâu), còn Priority là mức ưu tiên sửa (nên sửa gấp tới đâu theo góc nhìn nghiệp vụ). Ví dụ: lỗi gõ sai chính tả trên trang chủ có severity thấp nhưng priority cao (ảnh hưởng thương hiệu); ngược lại, một lỗi crash ở màn hình quản trị hiếm dùng có thể severity cao nhưng priority thấp hơn. Phân biệt sâu hơn ở bài Severity vs Priority.

Ví dụ một bug report chuẩn

Lấy lại màn hình đăng nhập của "Hệ thống đặt phòng họp nội bộ" làm ví dụ:

Bug ID: BUG_LOGIN_006 Title: Đăng nhập sai mật khẩu không hiển thị thông báo lỗi Module: Đăng nhập Environment: Chrome 138, Windows 11, môi trường staging, build 2.4.1 Severity: Major Priority: High Pre-condition: Đã có tài khoản hợp lệ; user chưa đăng nhập Steps to Reproduce: 1. Mở màn hình đăng nhập 2. Nhập email hợp lệ (user@itlearn.edu.vn) 3. Nhập mật khẩu sai (sai0000) 4. Bấm nút "Đăng nhập" Expected Result: Hiển thị thông báo "Email hoặc mật khẩu không đúng", vẫn ở màn hình đăng nhập. Actual Result: Trang chuyển sang màn hình trắng, không có thông báo, không điều hướng được. Attachments: screenshot_loi.png, video_taihien.mp4, console_log.txt Status: New Reported by: Tuan — 2026/06/21

Một bug report như trên dev gần như không có cớ để hỏi lại hay từ chối.

Mẹo để bug không bị reject

Bug bị reject thường không phải vì dev "khó tính", mà vì report chưa đủ rõ. Vài mẹo để tránh:

  • Tái hiện được 100%. Steps rõ ràng, mỗi bước một hành động; nếu lỗi xuất hiện không ổn định, ghi rõ tần suất.
  • Tách bạch Expected và Actual. Đừng chỉ viết "bị lỗi" — nói rõ lẽ ra thế nào và thực tế thế nào.
  • Đính kèm bằng chứng. Ảnh, video, log giúp dev tin và tái hiện nhanh.
  • Ghi đúng Environment. Rất nhiều lỗi chỉ xảy ra trên một trình duyệt/thiết bị/phiên bản cụ thể.
  • Kiểm tra trùng (duplicate) trước khi báo. Tránh log lại lỗi đã có.
  • Mỗi report một lỗi. Đừng gộp nhiều lỗi vào một report.
  • Đặt severity/priority khách quan, có lý do; tiêu đề mô tả đúng vấn đề, không cảm tính.

Làm tốt mấy điểm này, tỉ lệ bug bị reject của bạn sẽ giảm hẳn. 💪