Bug Life Cycle chi tiết: Từ phát hiện đến close để log bug đúng quy trình Agile

2 tháng trước · 10 phút đọc

Tại sao fresher hay log bug sai quy trình?

Mình nhớ lần đầu log bug trên Jira, mình chỉ gõ "Không đăng nhập được" rồi bấm tạo. Dev nhìn vào, nhắn lại: "Reproduce bằng cách nào?". Mình không biết trả lời. Cái bug đó bị để đó cả tuần vì không ai hiểu mình đang nói về lỗi gì.

Log bug không đủ thông tin không chỉ mất thời gian của dev, mà còn khiến bug "lọt" sprint mà không được fix. Trong môi trường Agile, mỗi sprint chỉ có 1-2 tuần. Bug log sai quy trình = bug bị reject = tính năng không qua được release.

Bài này mình đi từ đầu: bug là gì, vòng đời của nó trông như thế nào, ai chịu trách nhiệm ở từng bước, và viết bug report chuẩn trên Jira ra sao. Kèm template có thể copy ngay.

345989 Log bug thiếu thông tin khiến dev không reproduce được, bug nằm chờ hàng tuần

Bug Life Cycle là gì và tại sao cần hiểu rõ?

Bug Life Cycle (vòng đời của bug) là chuỗi các trạng thái mà một bug trải qua, từ lúc tester phát hiện đến khi QA lead xác nhận đóng lại. Không phải bug nào cũng đi thẳng từ "Mới" sang "Đóng" - có bug bị reopen, có bug bị reject vì không phải lỗi.

Hiểu vòng đời giúp bạn biết mình đang ở đâu trong quy trình, ai phải làm gì tiếp theo, và tránh để bug "lạc" ở trạng thái sai.

345990 Mỗi trạng thái có người chịu trách nhiệm khác nhau - nhầm lẫn là bug bị delay

6 trạng thái chính trong Bug Life Cycle

New (Mới): Tester vừa phát hiện và log bug lên hệ thống. Bug chưa được ai review.

Assigned (Đã phân công): QA lead hoặc PM review bug, xác nhận đây là lỗi thật, rồi assign cho dev xử lý.

In Progress (Đang xử lý): Dev đang fix. Trạng thái này đôi khi được gọi là "Open" ở một số team.

Fixed (Đã sửa): Dev báo đã fix xong, đẩy code lên, chuyển bug về cho tester verify.

Verified (Đã xác minh): Tester test lại bản build mới, xác nhận bug đã hết. Nếu chưa hết, tester reopen bug về trạng thái trước.

Closed (Đóng): QA lead xác nhận lần cuối, đóng bug. Sprint có thể release.

Ngoài ra có một số trạng thái phụ bạn sẽ gặp:

Rejected: Dev review thấy không phải bug, hoặc là behavior đúng theo spec
Deferred: Bug có thật nhưng không fix sprint này, dời sang sau
Duplicate: Bug giống một ticket đã có trước đó
Cannot Reproduce: Dev không tái hiện được, cần tester cung cấp thêm thông tin

Severity vs Priority: Hai khái niệm hay bị nhầm nhất

Mình thấy nhiều fresher log bug với Priority = Critical cho tất cả mọi thứ, kể cả lỗi typo. Điều này làm dev không biết fix cái nào trước, PM thì mất tin tưởng vào khả năng đánh giá của tester.

Severity (Mức độ nghiêm trọng) là bug ảnh hưởng đến hệ thống nặng đến đâu về mặt kỹ thuật. Do tester đánh giá.

Priority (Mức độ ưu tiên) là bug cần fix sớm đến đâu về mặt business. Do PM hoặc QA lead quyết định.

345991 Severity cao không đồng nghĩa Priority cao - phải hiểu cả hai mới log đúng

Bảng phân loại Severity:

Mức	Tên	Ý nghĩa	Ví dụ
S1	Critical	Hệ thống crash, không dùng được	App không mở được, payment bị mất
S2	High	Tính năng chính bị lỗi, không có cách thay thế	Login thất bại, không add được giỏ hàng
S3	Medium	Tính năng bị lỗi nhưng có cách thay thế	Sort filter sai thứ tự nhưng search vẫn dùng được
S4	Low	Lỗi nhỏ, không ảnh hưởng chức năng	Typo, lệch margin 2px

Ví dụ thực tế để phân biệt:

Bug A: Nút "Thanh toán" trên trang checkout bị ẩn vào cuối tháng khuyến mãi (chỉ xảy ra đúng ngày sale lớn). Severity = High (tính năng chính bị lỗi). Priority = Critical (ngày sale là ngày doanh thu cao nhất, cần fix ngay).

Bug B: App crash khi user nhập tên có ký tự tiếng Nhật (chỉ một tỷ lệ nhỏ user sử dụng tiếng Nhật trên app). Severity = Critical. Priority = Low (không ảnh hưởng đến đại đa số user hiện tại).

Thấy sự khác biệt chưa? Severity đánh giá mức độ kỹ thuật, Priority đánh giá mức độ ảnh hưởng business.

Vai trò của từng người trong Bug Life Cycle

Một trong những nhầm lẫn phổ biến của fresher: nghĩ rằng tester chỉ cần log bug xong là hết việc. Thật ra tester có trách nhiệm ở nhiều bước hơn bạn nghĩ.

345992 Tester không chỉ log - còn verify, reopen nếu cần, và confirm khi close

Tester (bạn - người mới):

Phát hiện bug, log đầy đủ thông tin lên Jira (trạng thái: New)
Verify lại sau khi dev báo Fixed - đây là bước quan trọng nhất mà fresher hay bỏ qua
Reopen bug nếu chưa fix xong hoặc fix sai
Đặt Severity ban đầu dựa trên đánh giá kỹ thuật

Developer (dev):

Nhận bug từ Assigned, tự reproduce để hiểu lỗi
Có thể Reject nếu không phải bug (kèm giải thích rõ lý do)
Fix và chuyển sang Fixed, mô tả ngắn đã fix cách nào

QA Lead:

Review bug New, xác nhận có đủ thông tin không trước khi Assign cho dev
Quyết định Priority dựa trên business
Quyết định Deferred hay Rejected khi cần
Close bug sau khi tester Verified

Một lưu ý quan trọng: khi dev Reject một bug của bạn, đừng vội bực. Xem lý do họ để lại. Đôi khi là do spec chưa rõ ràng, đôi khi là behavior được thiết kế như vậy. Nếu bạn thấy reject không hợp lý, escalate lên QA lead kèm evidence - không phải cãi trực tiếp với dev.

Cách viết bug report chuẩn trên Jira

Bug report tốt = dev reproduce được trong 5 phút. Bug report tệ = ticket nằm chờ cả tuần vì không ai hiểu.

Cấu trúc bug report chuẩn gồm 7 phần. Mình đi qua từng phần với ví dụ thực tế: bug login không hoạt động.

345993 Một bug report đủ 7 phần giúp dev fix trong cùng ngày thay vì mất cả tuần hỏi tới hỏi lui

1. Title (Tiêu đề)

Format: [Tính năng] + [Hành động] + [Kết quả sai]

❌ Tệ: "Lỗi login"
✅ Tốt: "[Login] Nhập đúng email + password vẫn báo 'Invalid credentials'"

2. Description (Mô tả ngắn)

1-2 câu tóm tắt lỗi. Dev đọc xong biết ngay đây là lỗi gì.

Khi user nhập đúng email và password đã đăng ký, hệ thống vẫn hiển thị thông báo lỗi 'Invalid credentials' thay vì chuyển vào trang dashboard.

3. Steps to Reproduce (Bước tái hiện)

Viết như recipe nấu ăn - ai làm theo cũng ra kết quả tương tự:

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

4. Expected Result (Kết quả kỳ vọng)

Hệ thống xác thực thành công, chuyển hướng user đến trang /dashboard

5. Actual Result (Kết quả thực tế)

Hệ thống hiển thị toast message đỏ: "Invalid credentials. Please try again." User không vào được dashboard.

6. Environment (Môi trường)

- Môi trường: Staging
- Browser: Chrome 124.0.6367.60
- OS: Windows 11
- App version: 2.4.1-RC

7. Evidence (Bằng chứng)

Attach screenshot, video màn hình, hoặc log lỗi từ console. Đây là thứ nhiều fresher bỏ qua nhất. Mình từng không attach screenshot, dev bảo "máy mình chạy bình thường" - ticket bị để đó 3 ngày.

Tải template bug report mẫu để copy-paste ngay: Tải template bug report mẫu

Quy trình Bug Life Cycle trong môi trường Agile

Agile khác với quy trình truyền thống ở một điểm quan trọng: thời gian ngắn. Sprint thường chỉ kéo dài 1-2 tuần, nên bug phải được xử lý nhanh và rõ ràng.

345994 Trong Agile, bug log sai hoặc chậm có thể đẩy lùi cả sprint planning

Bug trong Sprint như thế nào?

Bug được chia làm hai loại dựa trên thời điểm phát hiện:

Bug phát hiện trong sprint đang chạy: Tester tìm ra lỗi khi testing tính năng mới của sprint hiện tại. Bug này thường được fix ngay trong sprint nếu còn thời gian. Nếu không kịp, QA lead quyết định Deferred sang sprint sau.

Bug phát hiện từ sprint cũ (regression bug): Khi test tính năng mới, bạn vô tình phát hiện tính năng cũ bị hỏng. Loại này thường có Priority cao hơn vì ảnh hưởng đến tính năng đang production.

Daily flow của tester trong sprint

Một ngày của tester trong Agile sprint thường trông như thế này:

Sáng: Check Jira, xem bug nào dev đã Fixed hôm qua. Verify từng bug Fixed.
Trong ngày: Test tính năng mới trong sprint, log bug mới khi tìm thấy
Cuối ngày: Update trạng thái bug, confirm với QA lead những bug chưa rõ Priority

Điểm hay bị bỏ qua: Verify kỹ hơn chỉ check "chạy được"

Khi verify bug Fixed, mình không chỉ check đúng trường hợp đã log. Mình verify thêm:

Happy path: Trường hợp bug đã fix đúng chưa?
Edge case xung quanh: Dev fix bug A có vô tình tạo ra bug B không?
Regression nhẹ: Các tính năng liên quan có bị ảnh hưởng không?

Mình từng verify bug login Fixed chỉ bằng cách thử đúng account mẫu trong ticket, rồi Verified. Kết quả? Tài khoản có ký tự đặc biệt trong email vẫn không login được. Bug reopen, cả team mất thêm 2 ngày. Từ đó mình verify ít nhất 3 trường hợp trước khi bấm Verified.

Thấy khó ở bước verify này? Bình thường. Mình cũng mất vài sprint mới hình thành thói quen kiểm tra kỹ hơn case gốc.