# Bug Life Cycle & Cách Viết Bug Report Tốt

> 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…

- **URL canonical**: https://itlearn.edu.vn/blog/bug-life-cycle-bug-report
- **Published**: 2026-06-21T18:12:00+07:00
- **Modified**: 2026-06-21T20:36:35+07:00
- **Author**: Trung tâm IT Learn
- **Category**: Manual Testing (https://itlearn.edu.vn/blog/cat/manual-testing)
- **Reading time**: 9 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

Tìm ra lỗi mới là một nửa công việc của một [Manual Tester](/blog/manual-testing-la-gi-lo-trinh) — 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](/blog/cach-viet-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](/blog/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. 💪

## Câu hỏi thường gặp

### Bug life cycle gồm mấy trạng thái?

Không có con số cố định vì tùy quy trình và công cụ của từng đội, nhưng luồng điển hình gồm: New, Assigned, Open, Fixed, Pending Retest, Verified, Closed, cùng các nhánh rẽ như Reopened, Rejected, Duplicate và Deferred. Quan trọng là hiểu ý nghĩa và ai phụ trách ở mỗi trạng thái, hơn là học thuộc số lượng.

### Bug report cần những gì?

Tối thiểu cần: tiêu đề rõ ràng, môi trường, các bước tái hiện, kết quả mong đợi, kết quả thực tế, mức severity/priority và bằng chứng đính kèm (ảnh/video/log). Đủ những trường này là dev có thể tái hiện và sửa mà không cần hỏi lại bạn — đó là tiêu chí của một bug report tốt.

### Vì sao bug bị reject?

Thường vì report chưa đủ rõ: không tái hiện được, thiếu bước, thiếu môi trường, không tách Expected/Actual, hoặc thực ra không phải lỗi (do hiểu sai yêu cầu). Đôi khi lỗi bị trùng (duplicate) hoặc bị hoãn (deferred). Viết report đầy đủ và khách quan sẽ giảm hẳn tỉ lệ bị reject.

### Severity và Priority khác gì?

Severity là mức nghiêm trọng kỹ thuật của lỗi (ảnh hưởng hệ thống tới đâu), do tester đánh giá. Priority là mức ưu tiên sửa theo góc nhìn nghiệp vụ (nên sửa gấp tới đâu), thường do quản lý/PO quyết. Một lỗi có thể severity thấp nhưng priority cao, và ngược lại.

### Công cụ nào để quản lý bug?

Phổ biến nhất tại Việt Nam là Jira; ngoài ra còn Redmine, Bugzilla, Azure DevOps, hoặc bảng theo dõi đơn giản trên Excel/Google Sheets ở đội nhỏ. Công cụ chỉ hỗ trợ tổ chức và theo dõi; chất lượng bug report mới là yếu tố quyết định. Gặp thuật ngữ lạ, tra nhanh ở [thuật ngữ kiểm thử](/blog/thuat-ngu-kiem-thu/). Muốn thực hành báo lỗi và quản lý bug trên dự án thật, bạn có thể tham khảo [khóa Manual Testing](/newtester.html) của IT LEARN.