Bug Life Cycle: Hiểu Từ Phát Hiện Đến Close Để Trả Lời Đúng Khi Đi Phỏng Vấn
5 tháng trước · 8 phút đọc
Bug life cycle là gì và tại sao phỏng vấn hay hỏi?
Mình nhớ lần đầu đi phỏng vấn tester, HR hỏi: "Bạn có thể mô tả bug life cycle không?" Mình biết bug là lỗi, biết cách báo cáo, nhưng "life cycle" thì... đứng hình mất 5 giây.
Bug life cycle (vòng đời của bug) là toàn bộ hành trình một bug đi qua, từ lúc tester phát hiện ra cho đến khi nó được đóng lại hoàn toàn. Không phải bug nào cũng đi thẳng từ "phát hiện" sang "fixed". Có bug bị từ chối, có bug được mở lại, có bug nằm chờ cả tuần.
Tại sao nhà tuyển dụng hay hỏi câu này? Vì nó kiểm tra xem bạn có hiểu quy trình làm việc thực tế không, hay chỉ biết "tìm bug rồi báo cáo". Một tester hiểu bug life cycle sẽ biết: nên làm gì khi bug bị từ chối, khi nào cần retest, và khi nào bug thật sự được gọi là "xong".
Vòng đời bug không thẳng - có thể lùi, mở lại, bị từ chối
Bài này mình đi qua từng trạng thái một, giải thích bằng ví dụ ứng dụng đặt đồ ăn (quen thuộc, dễ hình dung). Đọc xong là bạn có thể trả lời câu hỏi phỏng vấn này mà không cần học thuộc lòng.
Trạng thái 1 - New: bug vừa được báo cáo
Tester tìm thấy lỗi, điền bug report, submit lên hệ thống (Jira, TestRail, hay bất kỳ tool nào team dùng). Lúc này bug ở trạng thái New.
Ví dụ: Bạn test tính năng đặt đồ ăn, nhập số điện thoại 11 số nhưng app không báo lỗi và vẫn cho đặt hàng. Bạn ghi lại đầy đủ: steps to reproduce, expected vs actual result, screenshot, rồi submit. Bug này vừa được tạo, chưa ai xem xét, trạng thái = New.
Bug ở trạng thái New thường do QA Lead hoặc Project Manager xem xét tiếp theo. Họ kiểm tra xem bug này có hợp lệ không, có đủ thông tin không, rồi quyết định bước tiếp theo.
Bug New = chưa ai nhận, chờ được phân loại và giao việc
Trạng thái 2 - Assigned: bug được giao cho dev
Sau khi QA Lead xem xét và xác nhận đây là bug thật, họ giao (assign) cho dev liên quan. Trạng thái chuyển sang Assigned.
Dev nhận được notification: "Này, có bug được giao cho bạn, xem đi." Nhưng họ chưa bắt tay vào làm, có thể đang bận task khác, có thể chờ clarify thêm thông tin.
Một điều nhiều tester mới không biết: bug ở Assigned không có nghĩa dev đang fix. Họ chỉ vừa nhận được thôi. Đây là lý do đôi khi bạn cần follow up nhẹ nhàng nếu bug quan trọng mà ngồi chờ mãi không thấy cập nhật.
Trạng thái 3 - Open: dev bắt đầu xem xét bug
Dev mở bug report ra đọc, xem xét và xác nhận "ừ, đây là bug thật, mình sẽ fix". Trạng thái chuyển sang Open.
Một số team bỏ qua bước Assigned và nhảy thẳng sang Open. Không sao cả - mỗi team có quy trình riêng. Điều quan trọng là bạn hiểu ý nghĩa: Open = dev đã acknowledge bug này và đang chuẩn bị hoặc đang trong quá trình xử lý.
Trạng thái 4 - In Progress: dev đang fix
In Progress (hoặc một số team gọi là "Fixed" khi dev xong) là lúc dev thật sự ngồi code để sửa lỗi. Trạng thái này cho cả team biết: bug đang được xử lý, đừng hỏi thêm.
Open vs In Progress: ranh giới mỏng nhưng quan trọng để track tiến độ
Ví dụ tiếp: Bug số điện thoại 11 số đã được giao cho dev backend. Dev mở ra xem, xác nhận thiếu validation ở API, và bắt đầu viết code fix. Trạng thái lúc này là In Progress.
Tip quan trọng khi phỏng vấn: Một số công ty không dùng cả Assigned lẫn Open, họ chỉ dùng 1 trong 2. Bạn nên nói thêm câu này: "Tùy theo quy trình của từng team, một số bước có thể được gộp lại." Câu này cho thấy bạn linh hoạt và hiểu thực tế công việc, không chỉ học thuộc lý thuyết.
Trạng thái 5 - Resolved: dev nói đã fix xong
Dev sửa xong, đổi trạng thái sang Resolved và thông báo cho tester: "Mình fix rồi, bạn test lại đi."
Đây là điểm nhiều tester mới hay nhầm. Resolved không có nghĩa là bug đã xong. Nó có nghĩa là dev cho rằng đã fix xong. Tester cần kiểm tra lại thực tế.
Dev còn có thể resolve bug với nhiều lý do khác nhau:
- Fixed: đã sửa
- Not a Bug: đây là behavior đúng theo spec, không phải lỗi
- Duplicate: bug này đã có người report trước rồi
- Cannot Reproduce: dev không tái hiện được lỗi
- Deferred: biết là bug nhưng để sau fix, không phải ưu tiên hiện tại
Resolved có nhiều loại - tester cần đọc kỹ lý do trước khi retest
Ví dụ: Dev resolve bug số điện thoại 11 số với trạng thái "Fixed", kèm note: "Đã thêm validation giới hạn 10 số ở màn hình nhập số điện thoại." Bạn nhận thông báo và bắt đầu bước tiếp theo.
Trạng thái 6 - Retest: tester kiểm tra lại
Khi bug chuyển sang Resolved, tester nhận nhiệm vụ Retest - kiểm tra lại xem dev có fix đúng chỗ, đúng cách không.
Retest không phải test nhanh cho xong. Mình thấy đây là bước nhiều người coi nhẹ nhất, và cũng là bước gây ra vấn đề nhiều nhất.
Khi retest, bạn cần kiểm tra ít nhất 3 thứ:
- Bug gốc đã hết chưa (test đúng scenario đã báo cáo)
- Fix này có gây ra lỗi khác không (kiểm tra các tính năng liên quan)
- Edge cases xung quanh còn ổn không
Retest không phải 'test nhanh cho xong' - đây là bước quyết định bug có thực sự xong không
Ví dụ: Bug số điện thoại đã resolved. Khi retest, bạn không chỉ test lại 11 số. Bạn kiểm tra thêm: 9 số (thiếu), 10 số (đúng), 12 số (thừa), ký tự chữ cái, khoảng trắng, số 0 ở đầu. Và kiểm tra xem tính năng đặt hàng chính vẫn chạy tốt không.
Nếu fix đúng và không có lỗi mới? Bug chuyển sang Closed. Nếu vẫn còn lỗi hoặc fix chưa đủ? Bug chuyển sang Reopened.
Trạng thái 7 - Closed: bug chính thức kết thúc
Closed là trạng thái mà bug không còn tồn tại trong quy trình nữa. Tester đã retest, xác nhận fix đúng, không có lỗi phát sinh, và đóng bug lại.
Chỉ tester (hoặc QA Lead) mới có quyền đóng bug, không phải dev. Đây là nguyên tắc quan trọng - vì dev không thể tự xác nhận fix của chính mình là đúng.
Trạng thái 8 - Reopened: bug tái xuất
Retest thấy bug vẫn còn? Hoặc bug đã Closed nhưng sau đó xuất hiện lại ở version mới? Trạng thái chuyển sang Reopened.
Reopened không phải thất bại - đây là phần bình thường của quy trình
Ví dụ: Dev fix validation số điện thoại ở màn hình nhập tay, nhưng bạn retest thấy nếu paste số 11 chữ số vào thì vẫn lọt. Bug chưa fix hoàn toàn. Bạn Reopen và ghi rõ trong comment: "Fix chưa cover trường hợp paste số - steps to reproduce: [...]."
Một điều mình hay nhắc bạn mới: Khi Reopen bug, đừng chỉ đổi trạng thái. Phải ghi comment chi tiết: retest ngày nào, test gì, thấy gì, steps reproduce. Dev cần thông tin đó để fix đúng lần này.
Bug Reopened sẽ quay lại vòng đời: dev nhận lại, fix, resolve, tester retest lần nữa. Vòng lặp này kết thúc khi bug được Closed thành công.