Phân biệt Bug, Defect và Fault: Tester fresher cần biết gì?

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

Ba từ, một sự nhầm lẫn rất phổ biến

Mình nhớ hồi mới bắt đầu học testing, mỗi lần thấy app lỗi là mình gõ thẳng vào Jira: "Bug: Bấm nút không làm gì". Xong. Tưởng vậy là đủ.

Rồi anh senior review, hỏi: "Đây là bug hay defect? Nguyên nhân ở code hay ở requirement?" Mình nhìn anh như người ngoài hành tinh.

Chuyện này xảy ra với rất nhiều fresher tester khi mới bắt đầu. Không phải vì lười, mà vì không ai giải thích rõ ba khái niệm này từ đầu: bug, defect, và fault. Nghe tương tự nhau, nhưng trong testing chuyên nghiệp, ba từ này chỉ ba thứ hoàn toàn khác nhau.

Hiểu đúng từ đầu sẽ giúp bạn viết bug report chính xác hơn, và quan trọng hơn: không bị hỏi ngớ ngẩn trong phỏng vấn fresher.

343096 Ba khái niệm tưởng giống nhau nhưng chỉ ba nguồn gốc lỗi khác nhau

Fault là gì? Đây là nguyên nhân gốc rễ

Trong testing, fault (còn gọi là error) là nguyên nhân gốc rễ gây ra lỗi. Nó thường xuất phát từ con người - developer gõ sai logic, hoặc analyst viết requirement mơ hồ.

Nói đơn giản: fault là cái gì đó SAI trong quá trình tạo ra phần mềm, nhưng chưa nhìn thấy được bằng mắt thường khi chạy app.

Ví dụ thực tế: Dev viết hàm tính tổng giỏ hàng, nhưng quên không cộng phí vận chuyển vào. Đoạn code logic đó - cái chỗ developer bỏ sót - chính là fault. Nó nằm im trong code, chưa gây ra lỗi nào cho đến khi user thực sự checkout.

343097 Fault ẩn trong code như bom hẹn giờ - chưa nổ nhưng đã sai từ đầu

Fault không nhìn thấy ngay. Nó chỉ lộ ra khi có điều kiện kích hoạt: user chạm đến đúng luồng đó, hoặc tester chạy đúng test case đó.

Đây là lý do tại sao testing cần phải kỹ. Một fault có thể nằm im cả tháng, đến khi khách hàng thật sự dùng mới phát hiện - lúc đó chi phí sửa tốn hơn rất nhiều so với phát hiện lúc test.

Defect là gì? Lỗi đã được xác nhận trong sản phẩm

Defect là khi fault được kích hoạt và tạo ra kết quả khác với mong đợi - và quan trọng là đã có người xác nhận nó tồn tại. Defect thường được phát hiện trong quá trình testing, sau khi tester chạy test case và so sánh kết quả thực tế với kết quả mong đợi.

Quay lại ví dụ giỏ hàng: tester chạy test case thanh toán, thấy tổng tiền hiển thị sai (thiếu phí ship). Tester ghi lại, mô tả rõ ràng, đính kèm screenshot - và log nó vào Jira. Cái được log vào Jira đó là defect.

343098 Defect là lỗi đã được chứng minh - có bằng chứng, có expected vs actual rõ ràng

Một điểm quan trọng: defect có thể xuất phát từ nhiều nguồn, không chỉ từ code. Nếu requirement viết sai (ví dụ: tài liệu ghi "phí ship miễn phí cho đơn trên 200k" nhưng thực ra chính sách là 300k), thì khi dev code đúng theo requirement sai đó, kết quả cũng ra defect.

Đó là lý do defect không phải lúc nào cũng là lỗi của developer. Đây là điểm nhiều fresher tester chưa hiểu, thường đổ hết cho dev mà không nhìn lại requirement.

Khi bạn phân loại defect đúng nguồn gốc (code sai hay requirement sai), team sẽ biết cần sửa ở đâu - dev hay BA. Điều này tiết kiệm rất nhiều thời gian.

Bug là gì? Và tại sao mọi người hay dùng nhầm?

Bug về mặt kỹ thuật nghiêm ngặt, là lỗi cụ thể nằm trong code - tức là developer viết sai logic, sai cú pháp, hoặc xử lý sai điều kiện. Bug là một dạng defect, nhưng nguyên nhân rõ ràng là code bị sai.

Ví dụ điển hình: function kiểm tra email nhưng chấp nhận "user@" không có domain. Logic code bị sai - đó là bug. Không phải requirement viết sai, không phải môi trường test lỗi, mà đúng là developer viết thiếu validation.

343099 Bug = lỗi code cụ thể, có thể trace về đúng dòng code sai

Tại sao trong thực tế mọi người dùng "bug" cho mọi thứ? Vì đây là từ thông dụng nhất, giống như mọi người gọi mọi loại photocopy là "Xerox" vậy. Trong team nhỏ, dùng "bug" cho mọi lỗi vẫn được chấp nhận.

Nhưng trong môi trường chuyên nghiệp hơn - đặc biệt khi làm với các team lớn, có quy trình SDLC (Software Development Life Cycle) rõ ràng - phân biệt đúng sẽ giúp prioritize và assign lỗi về đúng người xử lý.

Khái niệm	Nguồn gốc	Ai chịu trách nhiệm	Khi nào phát hiện
Fault	Sai sót trong quá trình tạo	Developer / Analyst	Trong review hoặc testing
Defect	Kết quả sai so với expected	Testing team xác nhận	Trong testing
Bug	Code sai cụ thể	Developer	Trong testing hoặc production

Bảng trên là tóm tắt nhanh. Không cần thuộc lòng, chỉ cần hiểu logic phía sau.

Mối quan hệ giữa ba khái niệm: hiểu theo chuỗi nhân quả

Ba khái niệm này không tồn tại độc lập - chúng liên quan nhau theo một chuỗi logic mà mình gọi là chuỗi nhân quả của lỗi phần mềm.

Fault là nguyên nhân. Defect là biểu hiện. Bug là một loại defect cụ thể.

Chuỗi điển hình diễn ra như thế này:

Developer bỏ sót điều kiện kiểm tra input rỗng khi viết code (→ fault xuất hiện)
Tester nhập trường họ tên để trống, bấm Submit, app crash (→ defect được phát hiện)
Tester log lên Jira: "App crash khi submit form với họ tên rỗng" (→ log defect/bug vào hệ thống)
Dev tìm ra đúng dòng code thiếu validation (→ tìm thấy fault gốc rễ)
Dev sửa code (→ fix fault, đóng defect)

343100 Chuỗi nhân quả từ fault đến defect đến fix - mỗi bước cần người khác nhau xử lý

Hiểu chuỗi này giúp bạn viết bug report tốt hơn. Thay vì chỉ ghi "app bị lỗi", bạn mô tả rõ: xảy ra ở đâu, khi làm gì, kết quả mong đợi là gì, kết quả thực tế là gì. Dev đọc vào là biết đi tìm fault ở đâu, không mất thời gian hỏi lại.

Nếu muốn tìm hiểu sâu hơn về quy trình testing từ cơ bản, khóa Kiểm thử phần mềm có một module riêng về vòng đời lỗi (bug life cycle) - từ phát hiện đến close rất bài bản.

Checklist phân loại khi log bug trên Jira/Redmine

Phần này thực chiến nhất trong bài. Mỗi lần phát hiện lỗi, trước khi log lên Jira hay Redmine, bạn nên tự hỏi 5 câu hỏi sau để phân loại cho đúng.

Câu 1: Lỗi này xuất phát từ đâu?

Code sai logic, sai validation → khả năng cao là bug
Requirement mơ hồ, thiếu sót, hoặc mô tả sai → defect từ requirement
Môi trường test lỗi (server down, database trống) → không phải bug, ghi chú riêng

Câu 2: Có thể reproduce được không? Nếu không reproduce được, đừng vội log. Thử lại 2-3 lần với điều kiện giống nhau. Defect không reproduce được rất khó fix và thường bị dev reject.

Câu 3: Expected result là gì? Phải có câu trả lời rõ ràng. Lấy từ requirement document, UI/UX mockup, hoặc common sense của user. Không có expected result rõ ràng → bug report của bạn sẽ bị trả lại.

Câu 4: Severity và Priority của lỗi này là gì?

Severity (mức độ nghiêm trọng kỹ thuật): Critical / High / Medium / Low
Priority (ưu tiên xử lý theo business): High / Medium / Low Hai cái này khác nhau. App crash là severity Critical, nhưng nếu tính năng đó ít người dùng, priority có thể Medium.

Câu 5: Đã có bug tương tự chưa? Tìm kiếm trong Jira trước khi log. Log trùng vừa làm rối hệ thống, vừa tốn thời gian team.

343101 5 câu hỏi này thành thói quen thì bug report của bạn ít bị reject hơn hẳn

Tải checklist đầy đủ để dán vào Notion hoặc in ra bàn làm việc: Tải checklist log bug chuẩn (HTML)

Viết bug report đúng: template thực tế

Biết phân loại rồi, nhưng viết thế nào mới là đủ tốt? Dưới đây là template mình hay dùng, đã áp dụng được ở hầu hết team.

Title: [Tính năng] + [Hành động] + [Kết quả sai] Ví dụ tốt: [Giỏ hàng] Submit form với họ tên rỗng → App crash màn hình trắng Ví dụ kém: Lỗi submit form

Steps to Reproduce (bước tái hiện lỗi):

1. Mở trang checkout: https://demo.shop.com/checkout
2. Để trống trường "Họ tên người nhận"
3. Nhấn nút "Đặt hàng"

Expected Result: App hiển thị thông báo lỗi "Vui lòng nhập họ tên" và giữ nguyên form.

Actual Result: App crash, màn hình trắng, không có thông báo lỗi.

Severity: High (crash toàn bộ luồng thanh toán)

Priority: High (ảnh hưởng trực tiếp user checkout)

Environment: Chrome 124, Windows 11, môi trường staging

Attachment: [Screenshot/Video]

343102 Bug report rõ steps to reproduce giúp dev tìm fault nhanh hơn - tránh mất 1-2 ngày hỏi qua lại

Mỗi trường trong template này đều có lý do. Steps to Reproduce rõ ràng giúp dev reproduce và tìm fault. Expected vs Actual phân biệt defect với "tính năng đang hoạt động đúng design". Environment giúp xác định lỗi có phải do môi trường không.

Một bug report thiếu bất kỳ trường nào trong số này đều có nguy cơ bị dev "reject" hoặc "need more info" - tức là mình phải làm lại từ đầu. Mình từng bị trả lại 4-5 bug report liên tiếp vì viết thiếu steps rõ ràng. Đau thật.

Câu hỏi phỏng vấn fresher hay gặp về chủ đề này

Nhiều bạn đọc đến đây vì chuẩn bị phỏng vấn - mình biết. Dưới đây là những câu interviewer hay hỏi và gợi ý trả lời ngắn.

"Bug và defect khác nhau thế nào?" Gợi ý: Bug là lỗi cụ thể trong code (developer viết sai). Defect rộng hơn - bất kỳ lỗi nào khiến sản phẩm không đáp ứng expected behavior, có thể từ code hoặc từ requirement. Mọi bug đều là defect, nhưng không phải mọi defect đều là bug.

"Fault là gì?" Gợi ý: Fault là nguyên nhân gốc rễ gây ra defect. Nó là sai sót xảy ra trong quá trình viết code hoặc viết requirement, chưa nhìn thấy bằng cách chạy app. Testing giúp kích hoạt fault và biến nó thành defect có thể nhìn thấy.

"Bạn sẽ phân loại defect theo severity và priority thế nào?" Gợi ý: Severity là mức độ nghiêm trọng về mặt kỹ thuật (ảnh hưởng đến hệ thống như thế nào). Priority là mức độ ưu tiên xử lý theo business (ảnh hưởng đến người dùng và công ty như thế nào). Hai cái có thể không đồng nhau - severity thấp nhưng priority cao, hoặc ngược lại.

343103 Trả lời rõ 3 câu này trong phỏng vấn là bạn đã vượt qua phần kiến thức cơ bản

Thấy khó không? Thật ra không. Nắm được phần lý thuyết này, kết hợp với thực hành viết bug report thật (dùng app thật, tự tìm lỗi, tự log), bạn sẽ trả lời tự tin hơn nhiều. Khóa Kiểm thử phần mềm có phần bài tập thực hành log bug trên môi trường giả lập nếu bạn muốn có kinh nghiệm thật trước khi phỏng vấn.

Mình tin bạn làm được. 25, 30 hay 35 tuổi - không quan trọng. Quan trọng là hiểu đúng từ đầu, thực hành đủ kỹ.

Lửng Lọc Lõi