← Về trang Blog
Manual test

Mối quan hệ giữa các loại Error – Defect – Failure

admin· Đăng ngày 4 tháng 7, 2025
Mối quan hệ giữa các loại Error – Defect – Failure

Trong buổi daily standup, một tester nói "có một error ở màn hình thanh toán", developer nghe thành "code tao sai", còn PM lại ghi vào báo cáo là "một failure trên production". Ba người, ba cách hiểu, cùng một câu nói — và cuộc tranh luận kéo dài 20 phút sau đó hoàn toàn vô nghĩa vì không ai dùng đúng thuật ngữ.

Đây không phải chuyện chữ nghĩa cho vui. Khi Error, Defect và Failure bị dùng lẫn lộn, cả đội mất khả năng truy vết nguyên nhân gốc rễ, báo cáo bug thiếu chính xác, và việc đánh giá rủi ro trở nên cảm tính. Trong môi trường làm việc theo chuẩn quốc tế — đặc biệt khi cộng tác với team nước ngoài — dùng sai terminology theo chuẩn ISTQB còn làm giảm tính chuyên nghiệp và gây hiểu nhầm tốn kém. Mỗi thuật ngữ có một định nghĩa riêng và một vị trí cố định trong chuỗi nhân quả; nắm đúng chuỗi đó là nền tảng của giao tiếp QA hiệu quả.

Trong bài viết này, bạn sẽ nắm được:

  • Định nghĩa chuẩn ISTQB của ba thuật ngữ Error – Defect – Failure và điểm khác biệt cốt lõi.
  • Mối quan hệ nhân quả giữa chúng: ai sinh ra ai, và khi nào một khiếm khuyết mới trở thành sự cố.
  • Vì sao không phải defect nào cũng gây failure — và những nguyên nhân khác có thể tạo ra failure.
  • Cách áp dụng đúng thuật ngữ trong vai trò QA/Tester, Developer và Project Manager.

Vì sao phải hiểu đúng các thuật ngữ này?

Trong lĩnh vực kiểm thử phần mềm và đảm bảo chất lượng, việc sử dụng chính xác các thuật ngữ theo chuẩn ISTQB (International Software Testing Qualifications Board) là vô cùng quan trọng. Mỗi thuật ngữ đều có định nghĩa rõ ràng và một vai trò riêng biệt trong quy trình kiểm thử — và chúng không thể thay thế cho nhau.

Error (Lỗi) — hành động của con người

Định nghĩa ISTQB: "A human action that produces an incorrect result"một hành động của con người tạo ra kết quả không chính xác.

Đặc điểm

  • nguyên nhân gốc rễ của tất cả mọi vấn đề.
  • Do con người tạo ra (lập trình viên, BA, tester, v.v.).
  • Có thể xảy ra trong bất kỳ giai đoạn nào của dự án.
  • Còn được gọi là Mistake.

Ví dụ thực tế

  • Developer viết sai logic nghiệp vụ do hiểu nhầm requirement.
  • BA ghi sai yêu cầu do miscommunication với khách hàng.
  • Tester thiết kế test case không đúng do thiếu kinh nghiệm.

Nguyên nhân thường gặp

  • Thiếu kinh nghiệm.
  • Áp lực thời gian.
  • Thiếu thông tin hoặc thông tin sai.
  • Độ phức tạp cao của hệ thống.
  • Mệt mỏi, bất cẩn.

Defect / Bug (Khiếm khuyết) — lỗi nằm trong hệ thống

Định nghĩa ISTQB: "A flaw in a component or system that can cause the component or system to fail to perform its required function" — một khiếm khuyết trong thành phần hoặc hệ thống có thể khiến thành phần hoặc hệ thống không thể thực hiện chức năng yêu cầu.

Đặc điểm

  • hậu quả trực tiếp của Error.
  • Tồn tại trong code, thiết kế hoặc tài liệu.
  • Theo ISTQB: Bug = Defect = Fault (ba từ này đồng nghĩa).

Ví dụ thực tế

  • Đoạn code có logic sai trong function tính lương.
  • Thiết kế database có foreign key constraint sai.
  • Tài liệu requirements mô tả sai business rule.

Failure (Sự cố) — hành vi sai quan sát được

Định nghĩa ISTQB: "Deviation of the component or system from its expected delivery, service or result" — sự sai lệch của thành phần hoặc hệ thống so với kết quả, dịch vụ hoặc phân phối mong đợi.

Đặc điểm

  • hậu quả có thể quan sát được của defect.
  • Xảy ra khi defect được thực thi (run-time).
  • Người dùng cuối có thể trải nghiệm trực tiếp.
  • Không phải tất cả defect đều gây failure.

Ví dụ thực tế

  • Ứng dụng crash khi user nhập số âm vào field tuổi.
  • Website hiển thị trang trắng khi load.
  • Hệ thống tính sai tiền lương của nhân viên.

Lưu ý quan trọng. Failure có thể do defect, nhưng cũng có thể đến từ các nguyên nhân khác hoàn toàn: user sử dụng sai cách, môi trường bị lỗi, tấn công độc hại, hoặc điều kiện môi trường bất thường. Vì vậy, thấy một failure không có nghĩa là chắc chắn tồn tại một defect trong code.

Bảng phân biệt nhanh ba thuật ngữ

Khi cần đối chiếu nhanh trong lúc viết bug report hay phân tích root cause, hãy nhìn vào ba chiều: bản chất, nơi tồn tại và thời điểm xuất hiện.

Thuật ngữBản chất (định nghĩa ISTQB)Ví dụ minh hoạ
Error (Lỗi / Mistake)Hành động của con người tạo ra kết quả không chính xác — nguyên nhân gốc rễ.Developer hiểu nhầm requirement nên viết sai logic nghiệp vụ.
Defect / Bug / FaultKhiếm khuyết tồn tại trong code, thiết kế hoặc tài liệu — hậu quả của error.Function tính lương chứa đoạn logic sai do error nói trên.
Failure (Sự cố)Sai lệch quan sát được khi defect bị thực thi — hệ thống chạy không như mong đợi.Hệ thống tính sai tiền lương của nhân viên khi chạy thật.

Mối quan hệ theo chuẩn ISTQB

Ba thuật ngữ không nằm rời rạc mà tạo thành một chuỗi nhân quả rõ ràng — đây chính là mô hình tư duy cốt lõi cần ghi nhớ:

  1. Error (Human Action) — con người mắc lỗi.
  2. tạo ra
  3. Defect (Flaw in Code/System) — khiếm khuyết nằm trong sản phẩm.
  4. khi được thực thi có thể gây ra
  5. Failure (Observable Deviation) — sự cố mà người dùng quan sát được.

Mũi tên đi một chiều: một error sinh ra defect, và defect khi được thực thi mới có thể dẫn tới failure. Nhưng chuỗi này không tất định — defect có thể "ngủ yên" mãi mà không bao giờ tạo ra failure nếu nhánh code chứa nó không bao giờ chạy.

Vì sao điều này quan trọng với từng vai trò?

Với QA / Tester

  • Báo cáo bug chính xác theo terminology chuẩn.
  • Phân tích root cause hiệu quả.
  • Giao tiếp professional với team quốc tế.

Với Developer

  • Hiểu rõ nguồn gốc và tác động của vấn đề.
  • Debug theo hướng đúng đắn.
  • Cải thiện quy trình development.

Với Project Manager

  • Tracking và reporting theo chuẩn quốc tế.
  • Risk assessment chính xác.
  • Decision making dựa trên data đúng đắn.

Kinh nghiệm thực chiến. Khi viết một bug report, hãy tự hỏi: cái bạn đang ghi là error, defect hay failure? Phần lớn các phiếu lỗi nên mô tả một failure (triệu chứng quan sát được: bước tái hiện, kết quả thực tế vs. kỳ vọng), rồi để khâu phân tích chỉ ra defect tương ứng, và root cause analysis mới truy ngược về error. Tách bạch ba tầng này giúp cả đội tranh luận đúng vấn đề thay vì đổ lỗi nhầm chỗ.

Kết luận

Hãy ghi nhớ chuỗi tư duy một chiều: con người mắc Error → để lại Defect trong hệ thống → Defect khi được thực thi mới gây Failure. Việc hiểu đúng và sử dụng chính xác các thuật ngữ theo chuẩn ISTQB không chỉ nâng cao tính chuyên nghiệp mà còn đảm bảo giao tiếp hiệu quả trong môi trường làm việc quốc tế. Đây là nền tảng cần thiết cho mọi QA/Tester muốn phát triển sự nghiệp.

Bạn đã từng chứng kiến một cuộc tranh luận đi lệch hướng chỉ vì cả đội dùng sai thuật ngữ? Hãy chia sẻ kinh nghiệm áp dụng ISTQB trong công việc của bạn để cộng đồng cùng học hỏi.


Nguồn tham khảo

  • ISTQB Foundation Wikidot.
  • Tools QA — ISTQB Error Defect Failure, ISTQB Error Defect Failure Relationship.
  • GeeksforGeeks — Defect Bug Failure Diagram.