Bug Life Cycle chi tiết cho Tester Freshers: Từ phát hiện đến close đúng quy trình Agile
3 tháng trước · 11 phút đọc
Bug life cycle là gì và tại sao tester cần hiểu kỹ?
Mình nhớ lần đầu log bug, mình chỉ viết: "Trang đăng nhập bị lỗi" rồi để trạng thái "New" và... chờ. Dev nhìn vào, không hiểu lỗi gì, hỏi lại mình 5 câu. Mình trả lời. Dev fix. Mình kiểm tra lại thấy vẫn còn lỗi. Lại báo. Cứ thế vòng vo mất 3 ngày cho 1 bug đáng lẽ fix trong 2 tiếng.
Vấn đề không phải dev làm chậm. Vấn đề là mình không hiểu bug đi qua những trạng thái nào, và tester cần làm gì ở mỗi trạng thái đó.
Bug Life Cycle (vòng đời của bug) là quy trình từ lúc bug được phát hiện cho đến khi nó được đóng lại chính thức. Mỗi bug đều có trạng thái (status), và trạng thái đó thay đổi theo từng hành động của tester, dev, hay team lead.
Hiểu bug life cycle giúp bạn:
- Log bug đúng cách ngay từ đầu, không bị trả lại
- Biết mình cần làm gì tiếp theo thay vì ngồi chờ
- Làm việc nhịp nhàng với dev trong sprint Agile
- Không để bug "rơi vào quên lãng" giữa chừng
Mỗi bug đều có vòng đời riêng - không phải cứ báo xong là xong
Trấn an trước: Nhìn vào sơ đồ bug life cycle lần đầu thấy nhiều trạng thái, dễ bị hoang mang. Thực ra khi đi làm, bạn chỉ thường xuyên gặp 5-6 trạng thái chính. Phần còn lại xử lý tình huống phát sinh thôi.
Các trạng thái trong bug life cycle - giải thích từng cái
Dưới đây là các trạng thái phổ biến nhất bạn sẽ gặp khi làm tester. Mình dùng tên tiếng Anh vì Jira, Redmine, hay các tool quản lý bug đều hiển thị vậy.
Quy trình bug đi theo chiều này - tester cần nắm rõ để không bỏ sót bước
New - Bug vừa được tester phát hiện và log vào hệ thống. Chưa ai xem xét. Đây là trạng thái bạn set khi tạo bug report lần đầu.
Open (Assigned) - Team lead hoặc PM xem xét bug, thấy hợp lệ, và assign cho dev xử lý. Ở bước này, bug được xác nhận là thật và cần fix.
In Progress - Dev đang fix bug. Tester không cần làm gì, chỉ cần chú ý khi nào bug chuyển sang bước tiếp theo.
Fixed (Ready for Retest) - Dev fix xong, chuyển bug về cho tester kiểm tra lại. Đây là lúc tester phải vào cuộc và kiểm thử lại.
Retest - Tester đang kiểm tra lại bug sau khi dev fix. Không skip bước này dù bug "trông có vẻ ổn". Mình từng bị qua mặt vì cái lỗi vẫn còn nhưng ẩn ở một điều kiện khác.
Verified - Tester xác nhận bug đã được fix đúng. Bug không còn xuất hiện trong các điều kiện đã test.
Closed - Bug chính thức đóng lại. Thường do team lead hoặc QA lead xác nhận lần cuối. Một số team để tester close luôn.
Reopened - Bug được mở lại vì vẫn còn lỗi sau khi đã "Verified" hoặc bị bỏ sót. Đây là trạng thái bạn set khi retest mà thấy bug chưa fix xong.
Ngoài ra còn một số trạng thái bạn sẽ gặp tùy team:
| Trạng thái | Ý nghĩa | Ai set? |
|---|---|---|
| Deferred | Hoãn fix, sprint sau xử lý | PM / Team Lead |
| Rejected / Invalid | Bug không hợp lệ hoặc là behavior đúng | Dev / Team Lead |
| Duplicate | Đã có bug tương tự được log trước | Team Lead / Tester |
| Won't Fix | Biết có bug nhưng không fix (ít quan trọng) | PM |
Khi bug bị Rejected, đừng buồn. Có thể tester hiểu sai requirement, hoặc đó là thiết kế cố ý. Hỏi lại để hiểu, không phải để tranh luận.
Bug life cycle trong Agile/Scrum khác gì so với Waterfall?
Nếu bạn đọc tài liệu cũ về bug life cycle, phần lớn mô tả quy trình theo mô hình Waterfall - tức là test giai đoạn cuối, bug được log tập trung rồi fix. Nhưng hiện tại phần lớn công ty tech Việt Nam chạy theo Agile hoặc Scrum, nên cách vận hành bug cũng khác đi.
Agile và Waterfall xử lý bug theo cách rất khác nhau
Trong Agile/Scrum, bug được xử lý ngay trong sprint (thường 1-2 tuần). Tester làm việc song song với dev, không phải chờ dev xong mới test. Điều này có nghĩa:
Bug phát hiện trong sprint hiện tại thường được fix trong sprint đó luôn, nếu đủ thời gian và đủ priority.
Bug phát hiện gần cuối sprint có thể bị Deferred sang sprint sau nếu team không kịp xử lý. Điều này bình thường trong Agile, không phải thất bại.
Daily Standup là lúc tester báo cáo số bug đang Open, bug nào cần retest, bug nào bị block. Bạn phải nắm trạng thái bug của mình mỗi ngày.
Bug phải gắn với User Story hoặc Task trong Jira. Khi log bug, bạn cần link nó với item trong sprint backlog để PM theo dõi được.
Một điểm khác biệt quan trọng: trong Agile, tester không chỉ test cuối sprint. Bạn tham gia Sprint Planning để hiểu scope, viết test case trước khi dev code xong, và bắt đầu test ngay khi tính năng đầu tiên ready. Không ngồi chờ toàn bộ sprint xong.
Nếu bạn mới vào team Agile và chưa quen văn hóa này, mình khuyên hỏi thẳng Scrum Master hoặc QA Lead: "Khi nào mình nên bắt đầu test trong sprint?" Hỏi thẳng tốt hơn ngồi chờ rồi test dồn cuối sprint.
Cách log bug đúng chuẩn để không bị dev trả lại
Bug bị trả lại (Rejected hoặc "Cannot Reproduce") thường không phải vì bug không có thật. Phần lớn là do bug report thiếu thông tin.
Mình đã từng nhận bug report từ tester mới với nội dung: "Bấm vào nút thì bị lỗi". Dev nhìn vào không biết nút nào, bấm lúc nào, lỗi gì. Kết quả? Bug bị Rejected vì "Cannot Reproduce".
Một bug report đủ chuẩn gồm:
1. Title - Ngắn, rõ, đủ thông tin. Tránh kiểu "Trang X bị lỗi". Nên viết: "[Thanh toán] Bấm 'Đặt hàng' với giỏ hàng trống vẫn chuyển sang trang xác nhận"
2. Environment - Môi trường test: browser nào, version nào, OS, device, build version. Dev cần cái này để reproduce.
3. Steps to Reproduce - Các bước để tái hiện bug, đánh số từng bước, rõ ràng từng action. Ví dụ:
1. Mở trang giỏ hàng (cart)
2. Xóa tất cả sản phẩm
3. Bấm nút "Đặt hàng"
4. Expected Result - Kết quả mong đợi (theo requirement hoặc logic người dùng)
5. Actual Result - Kết quả thực tế đang xảy ra
6. Severity & Priority - Mức độ nghiêm trọng (Critical/High/Medium/Low) và mức độ ưu tiên
7. Attachments - Screenshot, video record màn hình, log lỗi nếu có
Bug report đủ thông tin giúp dev reproduce ngay lần đầu
Về Severity vs Priority - hai khái niệm này hay bị lẫn:
- Severity (mức độ nghiêm trọng): Bug ảnh hưởng hệ thống nặng đến mức nào? Crash app = Critical. Lỗi typo = Low.
- Priority (mức độ ưu tiên): Cần fix sớm đến mức nào? Bug trên trang thanh toán dù nhỏ vẫn có thể High Priority vì ảnh hưởng doanh thu.
Tải template bug report mình hay dùng tại đây: Tải template bug report
Một lưu ý nhỏ: Khi bug reproduce được 1 trong 3 lần thử, vẫn log. Ghi rõ "Reproduced 1/3 times" trong bug report. Bug không ổn định (intermittent) vẫn cần được track.
Vai trò của tester trong từng giai đoạn bug life cycle
Nhiều bạn mới vào nghề nghĩ tester chỉ có 2 việc: tìm bug và báo bug. Thực tế tester tham gia nhiều hơn thế trong cả vòng đời của bug.
Tester không chỉ log bug - còn cần theo dõi và xác nhận đến khi Close
Khi bug ở trạng thái New: Bạn vừa log bug xong. Việc của bạn là đảm bảo bug report đủ thông tin, assign đúng người review (thường là QA Lead hoặc Team Lead).
Khi bug ở Open/In Progress: Sẵn sàng trả lời câu hỏi từ dev nếu họ cần thêm thông tin. Đừng log bug xong rồi "bay". Dev hỏi mà không có tester phản hồi sẽ mất thêm thời gian.
Khi bug ở Fixed/Ready for Retest: Đây là lúc tester làm việc nhiều nhất. Bạn cần:
- Reproduce lại đúng steps trong bug report
- Verify bug đã fix theo expected result
- Kiểm tra thêm các edge case liên quan - đôi khi dev fix chỗ này nhưng vỡ chỗ khác
- Chạy regression testing nhẹ cho các tính năng liên quan
Khi bug ở Verified: Cập nhật trạng thái lên Closed hoặc báo QA Lead review lần cuối, tùy quy trình team.
Khi bug bị Rejected: Đọc kỹ lý do. Nếu bạn không đồng ý, đặt câu hỏi với bằng chứng (screenshot, requirement document), không phải tranh luận cảm tính. Nếu đồng ý là mình hiểu sai requirement, ghi chú lại để học.
Khi bug bị Deferred: Theo dõi bug đó vào sprint tiếp theo. Nhiều team có habit "deferred là quên". Tester cần nhắc nhở trước sprint planning.
Một kỹ năng ít được nhắc đến: bug triage. Trong Agile, team thường có buổi triage ngắn để quyết định bug nào fix sprint này, bug nào defer. Tester cần trình bày rõ impact của từng bug để PM và dev ra quyết định đúng.
Retest và regression testing - hai bước tester hay bỏ qua
Bỏ qua retest hoặc làm qua loa là lý do phổ biến nhất khiến bug "tái sinh" production. Mình từng skip regression vì nghĩ "dev chỉ sửa 1 dòng code nhỏ thôi". Kết quả: tính năng ở màn hình khác bị vỡ. Bug đó nổ production và mình phải làm lại toàn bộ test cho module đó.
Retest là kiểm tra đúng bug đã fix hay chưa. Bạn chạy lại đúng steps trong bug report và verify expected result.
Regression testing (kiểm thử hồi quy) là kiểm tra các tính năng liên quan để đảm bảo việc fix bug không làm hỏng thứ khác. Ví dụ: dev fix bug ở form đăng ký → bạn cần test thêm đăng nhập, reset password, và các flow liên quan đến user account.
Retest và Regression khác nhau - cả hai đều cần thiết sau mỗi bug fix
Trong Agile sprint ngắn, regression testing thường là "regression nhẹ" - không test toàn bộ hệ thống mà chỉ test scope liên quan đến bug. Test toàn bộ thường để cuối sprint hoặc trước release.
Checklist retest cơ bản:
- Reproduce lại bug theo steps cũ → phải không còn xảy ra
- Test thêm 2-3 biến thể của điều kiện bug (ví dụ: bug xảy ra với user A, thử thêm với user B)
- Test trên môi trường/device khác nếu bug liên quan đến compatibility
- Kiểm tra log lỗi không còn error liên quan (nếu có quyền xem)
Bao nhiêu lần retest là đủ? Không có con số cố định. Nhưng nguyên tắc của mình: test đủ để tự tin báo cáo "bug này đã fix" mà không lo bị gọi lại. Nếu còn nghi ngờ, test thêm.