Bug Life Cycle: Từ Phát Hiện Đến Fix, Fresher Cần Hiểu Gì?
7 tháng trước · 11 phút đọc
Bug life cycle là gì và tại sao fresher hay bị hỏi?
Mình nhớ lần đầu phỏng vấn QA, câu hỏi thứ hai interviewer đặt ra là: "Em mô tả bug life cycle được không?". Lúc đó mình biết bug là lỗi, biết viết bug report - nhưng "life cycle" thì... ngập ngừng mất 5 giây.
Thực ra bug life cycle không phức tạp. Nó chỉ là hành trình của một bug từ lúc tester phát hiện cho đến khi bug đó chính thức được đóng lại. Hiểu đúng quy trình này giúp bạn biết mình đang cần làm gì ở từng giai đoạn, phối hợp với dev ra sao, và không bỏ sót bước nào quan trọng.
Lý do các công ty luôn hỏi bug life cycle ở vòng interview fresher: nó phản ánh bạn có hiểu quy trình làm việc thực tế không, chứ không chỉ biết "test cho có".
Mỗi bug đều có hành trình riêng - biết rõ từng bước giúp bạn không bỏ sót
Bài này mình đi từng trạng thái một, ví dụ thực tế, và cuối bài có checklist 7 bước để bạn theo dõi bug không bị lạc.
7 trạng thái trong bug life cycle
Hầu hết công ty dùng từ 5 đến 9 trạng thái tùy theo quy trình nội bộ. Nhưng bộ chuẩn mà fresher cần thuộc là 7 trạng thái này:
Trạng thái nào cũng có người chịu trách nhiệm - biết rõ để không đùn đẩy nhau
1. New (Mới) Tester phát hiện bug, tạo bug report trên hệ thống (Jira, Redmine, v.v.). Bug chưa được ai review. Đây là trạng thái bạn phải điền đủ thông tin: tiêu đề, mô tả, bước tái hiện, môi trường, severity, priority.
2. Assigned (Đã giao) Lead hoặc QA Manager review bug report. Nếu hợp lệ, bug được giao cho dev có trách nhiệm fix. Nếu không hợp lệ (duplicate, không phải bug, thiếu thông tin), bug bị reject hoặc trả về.
3. Open (Đang xử lý) Dev nhận bug và bắt đầu investigate. Ở trạng thái này, dev có thể đặt câu hỏi ngược lại với tester để hiểu rõ hơn. Tester cần phản hồi nhanh, không để bug "treo" vì chờ thông tin.
4. Fixed (Đã sửa) Dev sửa xong và deploy lên môi trường test. Dev tự mark bug là Fixed và thông báo cho tester biết để retest. Lưu ý: Fixed không có nghĩa là done - tester vẫn phải kiểm tra lại.
5. Retest (Kiểm tra lại) Tester thực hiện kiểm thử lại (retest) đúng theo bug report ban đầu. Bước này mình thấy fresher hay bỏ qua hoặc làm qua loa nhất. Không test lại kỹ là sai.
6. Verified (Đã xác nhận) Tester xác nhận bug đã fix đúng và không gây ra lỗi mới. Sau bước này, tester mới được phép chuyển bug sang Closed.
7. Closed (Đã đóng) Bug chính thức kết thúc. Không ai được mở lại trừ khi bug tái xuất hiện - lúc đó sẽ tạo bug mới hoặc reopen bug cũ tùy theo quy trình công ty.
Lưu ý thực tế: Một số công ty thêm trạng thái Reopened (mở lại) khi bug tái hiện sau khi đã Closed, hoặc Deferred (hoãn) khi bug được xác nhận nhưng chưa cần fix gấp. Gặp thêm trạng thái nào thì hỏi lead, không đoán mò.
Ví dụ thực tế: bug ở tính năng đăng nhập
Hiểu lý thuyết xong, mình ví dụ ngay để bạn hình dung rõ hơn. Tình huống: bạn đang test trang đăng nhập của một app thương mại điện tử.
Bước 1 - Phát hiện bug (New) Bạn nhập đúng email, đúng mật khẩu nhưng hệ thống hiện thông báo "Sai thông tin đăng nhập". Bạn thử lại 3 lần vẫn vậy. Đây là bug. Bạn tạo bug report trên Jira với:
- Tiêu đề: "[Login] Đăng nhập thất bại dù nhập đúng thông tin"
- Môi trường: Chrome 124, Android 14, staging
- Bước tái hiện: Vào trang login → nhập email/password đúng → nhấn Đăng nhập → Thấy thông báo lỗi
- Expected: Chuyển đến trang Home
- Actual: Hiện "Sai thông tin đăng nhập"
- Severity: Critical (tính năng core không dùng được)
Bug report rõ ràng giúp dev reproduce ngay, không mất thêm 1 buổi đi-lại hỏi nhau
Bước 2-3 - Assigned và Open Lead review, thấy bug report đủ thông tin, giao cho dev backend. Dev mở bug, kiểm tra phía server và phát hiện lỗi encoding mật khẩu sau lần deploy gần nhất.
Bước 4 - Fixed Dev fix xong, deploy lên staging, comment vào bug: "Fixed. Please retest on staging env."
Bước 5-6 - Retest và Verified Bạn quay lại test đúng theo bug report: đăng nhập với đúng tài khoản đó, đúng môi trường đó. Đăng nhập thành công. Bạn test thêm 2-3 tài khoản khác để chắc không phải may mắn. Tất cả đều ổn. Bạn chuyển trạng thái sang Verified.
Bước 7 - Closed Sau khi bạn verify, lead review và chuyển sang Closed. Bug kết thúc hành trình.
Tổng cộng: 1 bug đi qua 7 trạng thái trong 2 ngày. Không phức tạp, nhưng mỗi bước đều quan trọng.
5 sai lầm fresher hay mắc trong bug life cycle
Mình đã review bug report của không ít bạn mới vào nghề. Lỗi lặp đi lặp lại nhiều nhất không phải vì thiếu kiến thức - mà vì chưa hiểu TẠI SAO từng bước lại quan trọng.
Biết sai ở đâu mới tránh được - đừng để bug report bị reject lần đầu
Sai lầm 1: Thiếu thông tin trong bug report Viết tiêu đề kiểu "Lỗi đăng nhập" mà không có bước tái hiện, không có môi trường, không có expected/actual. Dev nhận bug không biết reproduce từ đâu, phải hỏi lại mất thêm nửa ngày. Hậu quả: bug fix chậm, và bạn bị đánh giá thiếu chuyên nghiệp.
Quy tắc mình hay nhắc: Bug report phải đủ để người chưa biết gì cũng reproduce được.
Sai lầm 2: Không retest kỹ sau khi dev fix Dev mark Fixed là xong phần của dev. Phần của bạn là kiểm tra lại - và không chỉ test đúng scenario cũ. Phải test thêm edge case xung quanh để chắc fix không gây lỗi mới (regression). Bỏ qua bước này, bug có thể tái hiện ở production và ai chịu trách nhiệm? Tester.
Sai lầm 3: Close bug khi chưa Verify đủ Một số bạn thấy dev nói "Fix rồi" là chuyển Closed luôn. Quy trình đúng: Fixed → Retest → Verified → Closed. Tester phải là người xác nhận, không phải dev tự close.
Sai lầm 4: Không update trạng thái bug kịp thời Bug treo ở New 3 ngày vì tester quên giao, hoặc Fixed 2 ngày mà tester chưa retest. Trạng thái bug phản ánh công việc đang ở đâu. Để sai trạng thái là gây nhầm lẫn cho cả team.
Sai lầm 5: Không giao tiếp khi cần thêm thông tin Khi dev mở bug và cần hỏi thêm, nhiều tester im lặng hoặc trả lời chậm. Dev bị chặn không fix được, bug bị delay. Testing không chỉ là ngồi test một mình - cần phối hợp liên tục.
Theo dõi bug trên Jira: giao diện thực tế
Hầu hết công ty dùng Jira để quản lý bug. Nếu bạn chưa dùng bao giờ, đừng lo - giao diện Jira học trong 30 phút là quen.
Một bug trên Jira thường gồm:
- Summary: Tiêu đề bug ngắn gọn, rõ ràng, có format
[Module] Mô tả vấn đề - Issue Type: Bug (phân biệt với Task, Story)
- Status: Trạng thái hiện tại trong life cycle
- Priority: Blocker / Critical / Major / Minor / Trivial
- Assignee: Người đang chịu trách nhiệm
- Description: Bước tái hiện, expected, actual, môi trường
- Attachments: Screenshot, video recording, log file
- Comments: Lịch sử trao đổi giữa tester và dev
Jira lưu toàn bộ lịch sử - lead có thể xem lại mọi bình luận và thay đổi trạng thái
Một mẹo nhỏ: Khi retest, comment rõ vào bug "Đã retest trên [môi trường], [version]. Bug đã fix / chưa fix." Đừng chỉ chuyển trạng thái mà không để lại ghi chú. Lead và dev sẽ hiểu bạn đã làm gì và kết quả ra sao.
Mình hay dặn các bạn mới: Jira là bằng chứng công việc của bạn. Điền đủ, comment rõ, update đúng lúc - đó là cách tester chứng minh mình làm việc có hệ thống.
Nếu bạn muốn thực hành Jira miễn phí, Atlassian có phiên bản free cho nhóm nhỏ: Jira Software Free - Atlassian.
Checklist 7 bước theo dõi bug - in ra dán bàn làm việc
Đây là checklist mình tổng hợp từ quá trình làm thực tế. Mỗi lần có bug mới, chạy qua 7 bước này để không bỏ sót gì.
In ra, dán bên cạnh màn hình - checklist nhỏ ngăn được bug lớn
Bước 1 - Viết bug report đủ thông tin
☐ Tiêu đề có format [Module] Mô tả
☐ Bước tái hiện đủ chi tiết (ai cũng reproduce được)
☐ Expected vs Actual rõ ràng
☐ Môi trường: browser, OS, version app
☐ Đính kèm screenshot hoặc video
Bước 2 - Set đúng Severity và Priority ☐ Severity: mức độ ảnh hưởng kỹ thuật (Blocker/Critical/Major/Minor) ☐ Priority: mức độ cần fix sớm theo nghiệp vụ ☐ Hai cái này khác nhau - đừng nhầm
Bước 3 - Submit bug và theo dõi trạng thái ☐ Bug đã được Assigned chưa? Nếu >1 ngày chưa có người nhận, hỏi lead ☐ Bug ở trạng thái Open quá lâu? Hỏi dev có bị stuck không
Bước 4 - Phản hồi khi dev hỏi thêm thông tin ☐ Trả lời trong vòng 2-4 giờ làm việc ☐ Provide thêm log, screenshot nếu cần
Bước 5 - Retest ngay khi dev mark Fixed ☐ Test đúng bước tái hiện trong bug report ☐ Test thêm 2-3 edge case liên quan ☐ Test regression: tính năng xung quanh có bị ảnh hưởng không
Bước 6 - Comment kết quả retest vào bug ☐ Nếu pass: "Retest on [env], [version]. Bug fixed. Chuyển Verified." ☐ Nếu fail: "Retest on [env], [version]. Bug vẫn tái hiện. Chuyển Reopened." + thêm evidence mới
Bước 7 - Verify và Close bug ☐ Tester (không phải dev) là người Verify ☐ Chỉ Close khi đã Verify xong ☐ Nếu bug tái hiện sau Closed: mở bug mới hoặc Reopen theo quy trình công ty
Tải checklist này để dùng ngay: Tải checklist 7 bước theo dõi bug
Thực ra bug life cycle không có gì khó. Khó là giữ kỷ luật làm đúng từng bước mỗi ngày, kể cả khi deadline gấp. Mình từng skip retest vì "thấy chắc chắn fix rồi" - và bug đó nổ production 3 ngày sau. Từ đó không bỏ bước nào nữa.
Nếu bạn đang chuẩn bị phỏng vấn fresher tester, nhớ 3 thứ: mô tả được 7 trạng thái, giải thích được TẠI SAO retest quan trọng, và biết cách viết bug report đủ thông tin. Chúc bạn pass!
Comment bên dưới nếu bạn có câu hỏi về bước nào trong life cycle - mình trả lời từng bạn.