Bug Life Cycle Chi Tiết: Tester Fresher Cần Hiểu Để Log Bug Chuẩn

6 tháng trước · 15 phút đọc

Bug, defect, fault - ba từ này có khác nhau không?

Mình nhớ hồi mới vào nghề, sếp hỏi: "Bug này là defect hay fault?" - mình đứng ngẩn ra không biết trả lời gì. Thật ra ba từ này thường được dùng lẫn lộn trong thực tế, nhưng về mặt kỹ thuật chúng có nghĩa khác nhau.

Fault (sai sót): là lỗi do con người tạo ra trong lúc code, thiết kế hoặc phân tích yêu cầu. Ví dụ: dev viết nhầm điều kiện > thành >=.

Defect (khuyết điểm): là khi fault đó tồn tại trong sản phẩm nhưng chưa nhất thiết gây ra hành vi sai. Nói đơn giản hơn, defect là "lỗi tiềm ẩn đang nằm im trong code".

Bug: là khi defect bị kích hoạt và gây ra hành vi sai thực sự khi chạy phần mềm. Người dùng hoặc tester bấm một nút, hệ thống sập - đó là bug bạn thấy.

343264 Ba khái niệm khác nhau nhưng thường bị dùng lẫn trong thực tế làm việc

Trong thực tế đi làm, bạn sẽ thấy team dùng "bug" cho cả ba trường hợp trên - và điều đó hoàn toàn ổn. Jira, Redmine đều gọi chung là "bug" hoặc "issue". Hiểu sự khác biệt giúp bạn mô tả vấn đề chính xác hơn khi làm việc với dev, đặc biệt khi cần escalate hoặc báo cáo.

Một điểm nữa: error (lỗi) là hành động sai của con người dẫn đến fault. Tức là: người làm sai (error) → tạo ra fault trong code → fault gây defect → defect bị kích hoạt thành bug → bug ảnh hưởng người dùng. Chuỗi này quan trọng vì giúp bạn hiểu: testing không chỉ tìm bug, mà là ngăn chặn từ sớm trong chuỗi đó.

Bug life cycle là gì và tại sao tester fresher hay nhầm?

Bug life cycle (vòng đời của bug) là quy trình một bug đi qua từ lúc được phát hiện đến khi được đóng lại chính thức. Nghe đơn giản, nhưng mình thấy rất nhiều fresher bỏ sót bước, assign bug sai người, hoặc close bug quá sớm - và kết quả là bug đó "sống lại" trên production.

Quy trình chuẩn thường gồm các trạng thái sau:

New - Tester phát hiện và log bug lần đầu. Đây là lúc bạn điền đầy đủ thông tin: tiêu đề, mô tả, bước tái hiện, kết quả thực tế, kết quả mong đợi, severity, priority.

Assigned - Bug được assign cho dev có trách nhiệm fix. Thường do lead hoặc PM làm bước này, nhưng tester cần biết để follow-up.

Open / In Progress - Dev đang xem xét hoặc fix. 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.

Fixed - Dev báo đã fix xong. Quan trọng: "Fixed" không có nghĩa là xong - đây là lúc tester phải vào verify.

Retest - Tester kiểm tra lại bug vừa được fix. Bước này nhiều fresher hay bỏ qua vì nghĩ "dev nói fix rồi thì thôi". Đừng vậy.

Verified - Tester xác nhận bug đã được fix đúng. Chỉ khi bạn tự kiểm tra và confirm, bug mới được chuyển sang bước tiếp.

Closed - Bug chính thức đóng. Thường do tester hoặc lead thực hiện sau khi Verified.

343265 Vòng đời một bug điển hình - mỗi bước đều có người chịu trách nhiệm

Ngoài nhánh chính, còn có các trạng thái ngoại lệ bạn sẽ gặp thường xuyên:

Rejected / Invalid: Dev xem xét và cho rằng đây không phải bug (đúng theo spec, môi trường test sai, v.v.). Lúc này bạn cần thảo luận lại dựa trên yêu cầu.
Duplicate: Bug đã được log bởi người khác trước đó. Hệ thống sẽ link hai bug lại.
Deferred: Bug có thật nhưng sẽ fix sau (thường do priority thấp hoặc deadline gấp).
Cannot Reproduce: Dev không tái hiện được bug với thông tin bạn cung cấp - đây là dấu hiệu bug report của bạn chưa đủ chi tiết.

Trạng thái "Cannot Reproduce" là lý do tại sao bước log bug ban đầu cực kỳ quan trọng. Mình từng bị reject bug vì mô tả thiếu môi trường test và version ứng dụng. Dev không reproduce được, bug bị mark là invalid, 2 tuần sau bug đó nổ lên production. Bài học đắt.

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

Đây là cặp từ mà mình thấy fresher nhầm nhiều nhất. Và nhầm ở đây có hậu quả: bug quan trọng bị xếp thứ tự ưu tiên thấp, bug nhỏ lại được fix gấp trong khi hệ thống đang cháy.

Severity (mức độ nghiêm trọng) - đo tác động của bug đến hệ thống. Do tester xác định dựa trên kỹ thuật:

Critical: Hệ thống crash, tính năng chính không dùng được, mất dữ liệu. Ví dụ: không thể đăng nhập vào app.
High: Tính năng quan trọng bị lỗi nhưng có workaround. Ví dụ: tính năng thanh toán lỗi nhưng có thể dùng cổng thanh toán khác.
Medium: Tính năng phụ bị ảnh hưởng, không block user flow chính. Ví dụ: filter sản phẩm trả về kết quả sai thứ tự.
Low: Lỗi nhỏ về giao diện, typo, màu sắc sai. Không ảnh hưởng chức năng.

Priority (mức độ ưu tiên xử lý) - quyết định bug nào được fix trước. Do PM hoặc lead xác định dựa trên business:

High: Cần fix ngay, có thể trong ngày.
Medium: Fix trong sprint hiện tại.
Low: Có thể đưa vào backlog, fix sau.

343266 Severity và Priority không luôn đi cùng nhau - hiểu đúng để không miss bug quan trọng

Tại sao hai cái này không phải lúc nào cũng giống nhau? Ví dụ thực tế:

Severity High, Priority Low: Tính năng export Excel bị lỗi (ảnh hưởng nhiều) nhưng chỉ 0.1% user dùng feature đó - business chấp nhận defer.
Severity Low, Priority High: Ảnh CEO bị hiển thị sai trên trang About Us - severity thấp (chỉ UI) nhưng priority cao vì lý do nhạy cảm.

Khi log bug, bạn điền severity (vì bạn là tester, bạn hiểu kỹ thuật). Còn priority thường do PM review và điều chỉnh. Nếu team nhỏ không có PM, tester và dev sẽ thống nhất cùng nhau.

Template log bug chuẩn - cái bạn cần copy ngay hôm nay

Một bug report tệ không phải vì bạn không giỏi, mà vì bạn chưa biết cần điền gì. Dev nhận bug report mà không reproduce được sẽ mark "Cannot Reproduce" và trả lại - mất thời gian của cả hai.

Dưới đây là template mình dùng và đã áp dụng trong nhiều project thực tế:

[BUG-ID] Tiêu đề ngắn, mô tả rõ vấn đề

Môi trường:
- OS: Windows 11 / macOS 14
- Browser: Chrome 124 / App version 2.1.3
- Môi trường: Staging / Production
- Tài khoản test: [email protected]

Bước tái hiện (Steps to Reproduce):
1. Mở trang đăng nhập
2. Nhập email hợp lệ, password chứa ký tự đặc biệt (@#$%)
3. Bấm nút Đăng nhập

Kết quả thực tế (Actual Result):
Hệ thống hiển thị thông báo lỗi "Invalid password" dù password đúng.

Kết quả mong đợi (Expected Result):
Đăng nhập thành công, chuyển đến trang Dashboard.

Severity: High
Priority: High

File đính kèm:
- screenshot_bug_001.png (ảnh chụp màn hình lỗi)
- video_repro.mp4 (nếu cần minh họa)

343267 Template này giảm đáng kể số lần bug bị reject vì "Cannot Reproduce"

Một số lưu ý khi điền template:

Tiêu đề bug - nhiều fresher viết kiểu "Lỗi đăng nhập". Quá chung chung. Hãy viết: "Đăng nhập thất bại khi password chứa ký tự đặc biệt trên Chrome 124". Dev đọc xong biết ngay đang xảy ra ở đâu, điều kiện nào.

Bước tái hiện - phải đủ cụ thể để người chưa biết gì về bug này có thể làm theo và thấy lỗi. Đừng bỏ qua bước nào dù "hiển nhiên".

File đính kèm - screenshot là bắt buộc. Video là điểm cộng. Khi bug khó mô tả bằng chữ, video 30 giây tiết kiệm 30 phút giải thích.

Tải ngay template log bug cho Jira/Redmine để dùng luôn: Tải template log bug (Jira/Redmine)

Log bug trên Jira và Redmine - khác gì nhau?

Hai công cụ này đều được dùng phổ biến tại các công ty Việt Nam. Jira phổ biến hơn ở công ty product và outsource nước ngoài, Redmine thường thấy ở công ty nội địa hoặc team nhỏ hơn. Bạn không cần chọn - đi làm dùng cái gì thì học cái đó.

Tiêu chí	Jira	Redmine
Giao diện	Hiện đại, nhiều tính năng	Đơn giản, cũ hơn
Workflow	Tùy chỉnh linh hoạt	Cấu hình cơ bản
Phổ biến tại VN	Rất phổ biến	Phổ biến ở team nhỏ
Chi phí	Có bản free (giới hạn)	Open source, miễn phí
Tích hợp	Confluence, Slack, GitHub...	Hạn chế hơn

Trên Jira, khi tạo bug mới:

Chọn project → Create Issue → Issue Type: Bug
Điền Summary (tiêu đề) - ngắn gọn, rõ ràng
Điền Description - dùng template ở trên
Chọn Priority (trong Jira, Severity thường điền trong Description)
Assign cho dev hoặc để trống cho lead assign
Đính kèm screenshot
Gắn label nếu cần (ví dụ: "regression", "ui", "api")

343268 Jira và Redmine khác giao diện nhưng cùng nguyên tắc log bug chuẩn

Trên Redmine, quy trình tương tự nhưng đơn giản hơn:

Chọn project → New Issue → Tracker: Bug
Điền Subject và Description
Chọn Priority và Assigned to
Gắn attachment

Một điểm quan trọng: dù dùng tool nào, nội dung bug report mới là thứ quyết định chất lượng. Tool chỉ là nơi lưu thông tin. Mình từng thấy tester log bug trên Jira với description chỉ có 1 câu "Bị lỗi" - dev không biết làm gì với thông tin đó cả.

Nếu team bạn dùng Jira và bạn muốn tìm hiểu workflow chi tiết hơn, Atlassian có document hướng dẫn khá đầy đủ: Hướng dẫn tạo issue trên Jira (Atlassian)

Những sai lầm phổ biến khi log bug - và cách tránh

"Cannot Reproduce" là câu dev hay trả lời nhất khi nhận bug report kém chất lượng. Mình tổng hợp 5 lỗi fresher hay gặp nhất, kèm cách sửa cụ thể.

Lỗi 1: Tiêu đề quá mơ hồ

Xấu: "Lỗi trang thanh toán"
Tốt: "Trang thanh toán crash khi nhập số thẻ chứa dấu cách trên Safari iOS 17"

Lỗi 2: Thiếu thông tin môi trường Dev không biết bạn test trên browser nào, version mấy, OS gì. Bug có thể chỉ xảy ra trên một môi trường cụ thể. Luôn điền: OS, browser/app version, môi trường (staging hay production).

Lỗi 3: Bước tái hiện thiếu bước Bạn test 10 bước mới thấy bug, nhưng chỉ viết 3 bước "chính". Dev làm theo 3 bước không thấy gì. Viết hết, kể cả bước "mở trình duyệt".

Lỗi 4: Không phân biệt actual vs expected Nhiều bạn viết mô tả chung chung: "Tính năng bị lỗi". Dev cần biết: hệ thống đang làm gì (actual) và đáng lẽ phải làm gì (expected). Hai thông tin khác nhau hoàn toàn.

Lỗi 5: Close bug trước khi verify Dev báo fix, bạn đổi status thành Closed ngay mà không test lại. Đây là sai lầm nguy hiểm nhất. Bước Retest → Verified là của tester, không ai làm thay bạn được.

343269 5 lỗi này gặp mỗi ngày - sửa được là chất lượng bug report tăng rõ rệt

Một tip thực chiến: trước khi submit bug, tự hỏi "Nếu mình là dev nhận bug này, mình có đủ thông tin để reproduce không?". Nếu câu trả lời là không chắc - bổ sung thêm.

Thấy khó ở bước đầu bình thường. Mình mất khoảng 2-3 tuần mới viết bug report đủ chất lượng để không bị reject. Quan trọng là làm nhiều, nhận feedback từ dev và cải thiện dần.

Tải checklist tự kiểm tra bug report trước khi submit: Tải checklist tự kiểm tra bug report

Regression testing sau khi bug được fix - bước cuối quan trọng nhất

Bug đã verified, đóng lại rồi. Xong chưa? Chưa.

Mỗi khi dev fix bug, họ sửa code. Sửa code có thể vô tình làm hỏng tính năng khác đang chạy tốt. Đó là lý do cần kiểm thử hồi quy (regression testing) - test lại các tính năng liên quan sau khi có thay đổi.

Ví dụ: bug ở tính năng thanh toán được fix. Bạn cần retest không chỉ thanh toán, mà còn giỏ hàng, lịch sử đơn hàng, email xác nhận - tất cả những gì có thể bị ảnh hưởng bởi thay đổi trong code thanh toán.

343270 Regression testing bảo vệ tính năng cũ khỏi bị "hỏng lây" sau mỗi lần fix bug

Trong thực tế, regression testing đầy đủ rất tốn thời gian. Đó là lý do automation test ra đời - để chạy regression nhanh hơn. Nhưng với fresher manual tester, bạn cần hiểu:

Không phải mọi bug fix đều cần full regression. Tập trung vào các tính năng liên quan trực tiếp đến phần code được sửa.
Test case regression cần được duy trì. Nếu team có test case suite, đây là lúc chạy lại.
Báo cáo kết quả regression. Không chỉ "chạy xong", mà phải ghi rõ đã test gì, pass/fail mấy test case.

Một chu kỳ bug life cycle hoàn chỉnh sẽ là: New → Assigned → In Progress → Fixed → Retest → Verified → Closed → Regression Testing (cho các tính năng liên quan). Chỉ khi toàn bộ chu kỳ đó hoàn tất, bạn mới thực sự chắc chắn release an toàn.

Testing không phải chỉ tìm bug. Tester tốt là người đảm bảo toàn bộ hệ thống vẫn chạy đúng sau mỗi thay đổi - từ bug nhỏ nhất đến tính năng lớn nhất. Đó là giá trị thực sự của vị trí này.

Bắt đầu từ đâu? Hãy thực hành log bug ngay hôm nay với app bất kỳ bạn đang dùng. Mở Jira bản free, tạo project thử nghiệm, và bắt đầu log những gì bạn thấy không đúng. Kỹ năng đến từ thực hành, không đến từ đọc lý thuyết.

Comment bên dưới nếu bạn có câu hỏi về bất kỳ bước nào trong bug life cycle. Mình đọc và trả lời từng bạn.

Lửng Lọc Lõi