Bug life cycle cho người mới: Từ phát hiện đến close để log bug đúng quy trình
3 tháng trước · 11 phút đọc
Bug life cycle là gì và tại sao fresher cần biết ngay?
Mình nhớ hồi mới vào nghề, log bug xong rồi... không biết làm gì tiếp. Dev hỏi "status hiện tại là gì?" - mình nhìn Jira mà không hiểu các ô màu kia nghĩa là gì. Cảm giác đó chắc nhiều bạn fresher đồng cảm.
Bug life cycle - hay còn gọi là vòng đời lỗi - là hành trình một bug đi qua từ lúc bạn phát hiện ra cho đến khi nó được đóng lại chính thức. Không phải bạn tìm thấy bug là xong. Mỗi bug cần đi qua một chuỗi trạng thái có thứ tự, có người chịu trách nhiệm ở từng bước.
Tại sao điều này quan trọng? Vì nếu bạn không hiểu vòng đời này, bạn sẽ:
- Log bug thiếu thông tin, dev không hiểu cần sửa cái gì
- Không biết khi nào cần retest, khi nào bug được close
- Để bug "trôi" không ai theo dõi, đến cuối sprint mới phát hiện chưa fix
Mỗi bug là một câu chuyện - có đầu, có cuối, có người chịu trách nhiệm từng bước
Bài này mình đi từng trạng thái một, giải thích rõ ý nghĩa và ví dụ thực tế. Đọc xong bạn sẽ tự tin log bug và cập nhật status mà không cần hỏi lại senior.
Các trạng thái trong bug life cycle
Phần này là trọng tâm. Mình sẽ giải thích từng trạng thái theo đúng thứ tự một bug thường đi qua.
Sơ đồ đầy đủ - một bug có thể đi qua nhiều vòng trước khi được close
New (Mới)
Bạn vừa tìm thấy lỗi và log vào hệ thống. Bug ở trạng thái New nghĩa là chưa ai review xem nó có hợp lệ không. Nhiệm vụ của bạn lúc này: mô tả đầy đủ, rõ ràng nhất có thể.
Assigned (Đã giao)
Test lead hoặc QA manager review bug của bạn và xác nhận nó hợp lệ. Họ giao bug đó cho dev cụ thể. Bạn không cần làm gì ở bước này, nhưng nên để ý bug được giao cho ai để biết ai sẽ fix.
Open (Đang xử lý)
Dev nhận bug, bắt đầu phân tích và sửa. Trạng thái này có thể kéo dài vài giờ đến vài ngày tùy độ phức tạp. Lúc này bạn có thể add thêm thông tin nếu phát hiện thêm, nhưng đừng liên tục ping dev.
Fixed (Đã sửa)
Dev đã fix xong và deploy lên môi trường test. Họ chuyển bug sang Fixed. Đây là lúc bạn cần hành động: nhận thông báo và bắt đầu retest ngay, đừng để bug chờ.
Retest (Kiểm tra lại)
Bạn chuyển status sang Retest khi bắt đầu kiểm tra lại bug đã được sửa. Một số team bỏ qua bước này, nhưng mình khuyên nên giữ vì nó cho mọi người biết bạn đang kiểm tra.
Verified (Đã xác nhận)
Bạn test xong, bug đã được sửa đúng. Chuyển sang Verified nghĩa là bạn xác nhận fix hoạt động đúng. Sau đó test lead hoặc bạn sẽ close bug.
Closed (Đóng)
Bug chính thức kết thúc vòng đời. Fix đúng, không còn lỗi. Một số dự án cần PM hoặc BA review thêm trước khi close.
Rejected (Bị từ chối)
Dev hoặc lead review và cho rằng đây không phải bug - có thể do behavior đúng với spec, hoặc bạn test sai môi trường. Bug bị Rejected cần bạn xem lại: nếu thấy mình đúng thì cần giải thích thêm bằng evidence (video, screenshot), nếu sai thì học từ đó.
Won't Fix / Deferred (Không sửa / Hoãn lại)
Hai trạng thái này ít gặp hơn nhưng có trong thực tế. Won't Fix: bug có thật nhưng team quyết định không sửa (thường do impact thấp, effort sửa quá lớn). Deferred: hoãn sang sprint sau hoặc version sau. Bạn không cần tranh luận - chỉ cần đảm bảo lý do được ghi rõ trong comment.
Ví dụ bug report thực tế - viết đúng từ đầu
Bug report tệ là nguyên nhân số một khiến bug bị trả về. Mình từng viết bug kiểu: "Không đăng nhập được" - dev nhìn vào không biết tái hiện bằng cách nào, hỏi lại mất thêm nửa ngày.
Dưới đây là mẫu bug report đúng chuẩn cho tính năng đăng nhập:
Viết đủ thông tin từ đầu giúp bug được fix nhanh hơn - không ai phải hỏi lại
Title: [Login] Đăng nhập thất bại khi password chứa ký tự đặc biệt (@, #, $)
Environment: Staging | Chrome 124 | Windows 11
Priority: High | Severity: Critical
Steps to reproduce:
1. Truy cập https://staging.app.com/login
2. Nhập username: [email protected]
3. Nhập password: P@ss#word$123
4. Click nút "Đăng nhập"
Expected result:
Hệ thống đăng nhập thành công, chuyển đến trang Dashboard.
Actual result:
Hiển thị thông báo lỗi "Sai tên đăng nhập hoặc mật khẩu"
mặc dù thông tin đúng.
Attachment: bug-login-special-char.mp4 (video tái hiện 30s)
Note:
- Password không chứa ký tự đặc biệt (P@ssword123 -> bỏ # và $)
thì đăng nhập thành công bình thường.
- Đã test trên Firefox 125, lỗi tương tự.
Bạn thấy điểm khác biệt không? Bug report này có:
- Title rõ module và điều kiện xảy ra lỗi: không chỉ viết "lỗi đăng nhập"
- Steps chi tiết đến mức ai copy paste cũng tái hiện được
- Expected vs Actual: nói rõ mong đợi gì, thực tế ra sao
- Evidence: video hoặc screenshot - đây là thứ bảo vệ bạn khi bug bị đặt câu hỏi
- Note: thông tin bổ sung giúp dev khoanh vùng nhanh hơn
Thời gian viết bug report kỹ lúc đầu khoảng 10-15 phút. Nhưng tiết kiệm được 1-2 tiếng hỏi đi hỏi lại giữa bạn và dev sau đó.
Cách cập nhật status trong công cụ quản lý lỗi
Hầu hết dự án dùng Jira, Redmine hoặc Azure DevOps để quản lý bug. Giao diện khác nhau nhưng logic giống nhau.
Jira là công cụ phổ biến nhất hiện tại. Khi cập nhật status trong Jira:
- Mở ticket bug cần cập nhật
- Tìm nút "Transition" hoặc dropdown status (thường ở góc trên phải ticket)
- Chọn trạng thái mới phù hợp
- Bắt buộc: thêm comment giải thích lý do thay đổi
Luôn thêm comment khi chuyển status - lịch sử này giúp ích khi cần review sau
Ví dụ comment khi chuyển sang các trạng thái:
- Chuyển sang Retest:
"Bắt đầu retest. Build: v2.3.1 - Deploy lúc 14:30 ngày 20/05" - Chuyển sang Verified:
"Đã retest thành công. Login với password chứa @#$ hoạt động đúng. Browser: Chrome 124, Firefox 125." - Chuyển sang Reopen:
"Bug chưa được fix hoàn toàn. Password chứa @ đã OK nhưng # vẫn lỗi. Screenshot đính kèm."
Một lưu ý nhỏ nhưng quan trọng: không được close bug khi chưa retest. Mình từng thấy fresher close luôn sau khi dev báo "fixed" mà không test lại - kết quả là bug vẫn còn trên production. Dev nói fixed không có nghĩa là thật sự hết lỗi trên môi trường test.
Ngoài Jira, nếu dự án dùng Redmine hoặc Trello, luồng tương tự nhưng cách đặt tên status có thể khác. Điều quan trọng là bạn hiểu ý nghĩa từng bước, còn tên gọi cụ thể thì đọc docs của dự án là nắm được ngay.
Những sai lầm khiến bug bị trả về
Đây là phần mình muốn bạn đọc kỹ nhất. Mình tổng hợp từ trải nghiệm thực tế và từ những lần observe fresher bị bug reject hoặc bị senior yêu cầu bổ sung.
Tránh được 5 sai lầm này, bug của bạn sẽ ít bị trả về hơn nhiều
Sai lầm 1: Title mơ hồ
"Lỗi thanh toán" - dev nhận bug này không biết bắt đầu từ đâu. Cần viết rõ: "[Thanh toán] Không nhận được email xác nhận sau khi thanh toán thành công qua VNPay". Module, hành động, kết quả sai - ba thứ đó cần có trong title.
Sai lầm 2: Thiếu steps to reproduce
Dev không thể fix bug mà họ không tái hiện được. Nếu steps của bạn không đủ chi tiết (bỏ qua điều kiện tiên quyết như "phải đăng nhập trước", "giỏ hàng phải có ít nhất 2 sản phẩm"), bug sẽ bị trả về kèm comment "Cannot reproduce".
Sai lầm 3: Không đính kèm evidence
Screenshot hoặc video là bằng chứng. Thiếu evidence khiến dev nghi ngờ bug có thật không - nhất là những bug khó tái hiện. Mình có thói quen record màn hình 30 giây tái hiện mỗi khi log bug.
Sai lầm 4: Close bug khi chưa retest kỹ
Dev sửa xong, bạn test qua happy path thấy OK rồi Verified. Nhưng quên test lại edge case - kết quả là bug tưởng closed lại nổ production. Khi retest, test ít nhất 3 scenarios: đúng như báo cáo, trường hợp giáp ranh, và tình huống liên quan gần.
Sai lầm 5: Không cập nhật status kịp thời
Dev fix xong, chuyển sang Fixed lúc 10h sáng. Bạn không để ý, đến chiều mới retest. Nếu là bug critical, cả team đang chờ. Hãy bật notification cho ticket được assign cho bạn hoặc check Jira mỗi buổi sáng và sau bữa trưa.
Một điểm mình hay nhắc: nếu bug bị Rejected, đừng tự ái. Đọc comment của dev/lead, tìm hiểu lý do. Đôi khi là do bạn test sai môi trường (test trên local thay vì staging), đôi khi là behavior theo design. Học từ mỗi lần bị reject nhanh hơn nhiều so với đọc tài liệu.
Thực hành ngay: log bug đầu tiên của bạn
Kiến thức về bug life cycle sẽ không ngấm nếu bạn chỉ đọc mà không làm. Mình gợi ý bài tập thực hành đơn giản để bắt đầu ngay hôm nay.
Bước 1: Vào trang web bất kỳ (có thể dùng các trang demo như trang web demo để thực hành tìm bug) và thử tìm một lỗi nhỏ - lỗi hiển thị, lỗi responsive, lỗi chức năng.
Bước 2: Mở Google Sheets hoặc Notion, viết bug report theo đúng cấu trúc mình chia sẻ ở phần trên. Tải mẫu về dùng luôn cho nhanh.
Bước 3: Tự hỏi: "Nếu mình là dev nhận bug này, mình có đủ thông tin để fix không?"
Thực hành với trang demo giúp bạn quen tay trước khi vào dự án thật
Nếu câu trả lời là "có" - bạn đã viết được một bug report chất lượng. Nếu "chưa" - thêm thông tin vào cho đủ.
Thấy khó ở bước đầu là bình thường. Mình mất cả tuần đầu tiên mới quen cách viết title cho đủ rõ. Bây giờ chỉ mất 10 phút log một bug report đúng chuẩn. Luyện nhiều, quen tay thôi.
Comment bên dưới nếu bạn có câu hỏi về bất kỳ trạng thái nào trong bug life cycle, hoặc muốn mình review bug report bạn tự viết. Mình đọc và trả lời từng bạn.
Bài tiếp theo mình sẽ hướng dẫn cách phân loại severity và priority - hai thứ hay bị nhầm nhất trong bug report của fresher. Bookmark để theo dõi nhé!