Error / Defect / Failure — bảng phân biệt nhanh

Theo ISTQB: error là sai sót của con người (a human action that produces an incorrect result), defect là khiếm khuyết nằm trong sản phẩm (sản phẩm code, tài liệu) do error gây ra, còn failure là biểu hiện sai lệch quan sát được khi phần mềm chạy. Nói ngắn: error là nguyên nhân từ người, defect là thứ tồn tại trong sản phẩm, failure là hiện tượng lúc vận hành.

Tiêu chí Error (sai sót) Defect / Bug (lỗi) Failure (sự cố)
Bản chất Hành động/suy nghĩ sai của con người Khiếm khuyết trong sản phẩm (code, tài liệu) Hành vi sai lệch so với mong đợi
Xảy ra ở đâu Trong đầu/ thao tác của người (dev, BA…) Nằm tĩnh trong sản phẩm đã tạo ra Khi phần mềm được thực thi (runtime)
Thời điểm Lúc viết code/ thiết kế/ phân tích Sau khi error được "cài" vào sản phẩm Khi chạy đúng nhánh code chứa defect
Ai gặp Người gây ra Tester/ reviewer phát hiện qua kiểm thử tĩnh hoặc động Người dùng/ hệ thống quan sát thấy
Từ đồng nghĩa mistake fault, bug sự cố, hỏng

Ba thuật ngữ này không thay thế cho nhau được. Hiểu sai một mắt xích là bạn vừa mất điểm thi, vừa viết bug report lủng củng khi đi làm. Muốn tra cứu thêm các định nghĩa chuẩn khác, bạn có thể xem thuật ngữ kiểm thử đầy đủ.

Error (sai sót của con người) là gì

Error (đồng nghĩa: mistake) là một hành động của con người tạo ra kết quả không đúng. Theo ISTQB, error luôn gắn với con người, không phải với máy. Lập trình viên hiểu nhầm requirement, BA viết thiếu một quy tắc nghiệp vụ, hay dev gõ nhầm dấu so sánh — tất cả đều là error.

Lấy ví dụ quen thuộc của series này: Hệ thống đặt phòng họp nội bộ. Requirement ghi "một phòng không được đặt trùng khung giờ". Bạn dev hiểu nhầm thành "không được trùng cùng ngày", thế là viết logic kiểm tra theo ngày thay vì theo khung giờ. Cái hiểu nhầm trong đầu anh ấy chính là error.

Error đến từ đâu? Thường là áp lực thời gian, requirement mơ hồ, thiếu kinh nghiệm, hoặc đơn giản là mệt mỏi cuối ngày. Điểm mấu chốt cần nhớ: error mới chỉ là nguyên nhân gốc. Bản thân nó chưa làm hỏng gì cả — cho tới khi nó được "đóng gói" vào sản phẩm dưới dạng defect.

Defect / Bug (lỗi trong sản phẩm) là gì

Defect (đồng nghĩa: fault, bug) là một khiếm khuyết trong một thành phần hay hệ thống, có thể khiến phần mềm không thực hiện đúng chức năng yêu cầu. Đây chính là câu trả lời cho thắc mắc defect là gì và lỗi phần mềm là gì: defect là dấu vết mà error để lại bên trong sản phẩm — thường là trong code, nhưng cũng có thể nằm trong tài liệu thiết kế hay requirement.

Quay lại Hệ thống đặt phòng họp: vì dev hiểu nhầm (error), đoạn code kiểm tra trùng lịch giờ đây so sánh theo ngày thay vì theo khung giờ. Dòng code sai đó là defect. Nó nằm yên trong sản phẩm, tĩnh, chờ tới lúc bị kích hoạt.

Đính chính theo chuẩn ISTQB: nhiều bài viết tiếng Việt dùng "bug" như đồng nghĩa của "error" — điều này không chính xác. Theo glossary ISTQB, bug là từ đồng nghĩa của defect (fault), tức là lỗi trong sản phẩm, KHÔNG phải sai sót của con người. Khi nói "tìm thấy một bug", bạn đang nói tới defect.

Defect được phát hiện bằng hai con đường: kiểm thử tĩnh (review, phân tích tĩnh — soi defect ngay trong code/tài liệu mà không chạy), và kiểm thử động (chạy phần mềm, quan sát failure rồi lần ngược về defect). Một defect sau khi được tester ghi nhận sẽ đi qua một quy trình xử lý; bạn có thể đọc kỹ ở bài vòng đời của bug để nắm cách viết và theo dõi defect report.

Failure (sự cố khi vận hành) là gì

Failure là sự kiện trong đó một thành phần hoặc hệ thống không thực hiện đúng chức năng yêu cầu trong giới hạn đã định — biểu hiện sai lệch quan sát được khi phần mềm chạy. Khác với defect (tĩnh, nằm trong sản phẩm), failure chỉ xuất hiện ở runtime, khi luồng thực thi đi đúng vào chỗ chứa defect.

Trong Hệ thống đặt phòng họp: một bạn nhân viên đặt phòng A lúc 9–10h, rồi một bạn khác cũng đặt đúng phòng A lúc 9h30. Đáng lẽ hệ thống phải chặn vì trùng khung giờ, nhưng nó lại cho qua (vì code so theo ngày). Hai lịch chồng nhau hiện ra trên màn hình — đó là failure. Người dùng nhìn thấy hậu quả; defect thì họ không thấy.

Một lưu ý ISTQB hay hỏi: failure phần lớn do defect, nhưng cũng có thể đến từ điều kiện môi trường (nhiễu điện từ, bức xạ, ô nhiễm, từ trường…) tác động lên phần cứng khiến phần mềm chạy sai, dù code hoàn toàn đúng. Trường hợp này hiếm trong ứng dụng web nghiệp vụ, nhưng vẫn nằm trong định nghĩa chuẩn. Để hiểu failure được "bắt" ở những đâu trong quá trình kiểm thử, xem thêm các loại kiểm thử.

Chuỗi nhân quả Error → Defect → Failure (ví dụ)

Cách dễ nhớ nhất là xâu ba khái niệm thành một chuỗi nhân quả error defect failure: con người sai (error) → để lại lỗi trong sản phẩm (defect) → lỗi đó bộc lộ khi chạy (failure). Đây là mạch tư duy ISTQB muốn bạn nắm thật chắc.

Mắt xích Trong Hệ thống đặt phòng họp
Error Dev hiểu nhầm requirement: chống trùng "theo ngày" thay vì "theo khung giờ"
Defect Đoạn code kiểm tra trùng lịch so sánh sai (theo ngày), nằm tĩnh trong sản phẩm
Failure Khi chạy: hai lịch 9–10h và 9h30 cùng phòng A được chấp nhận, hiển thị chồng nhau

Một điểm cực kỳ quan trọng: không phải defect nào cũng dẫn tới failure. Nếu nhánh code chứa defect không bao giờ được thực thi (ví dụ tính năng bị ẩn, hoặc điều kiện kích hoạt không bao giờ xảy ra trong thực tế), thì defect cứ nằm im mà người dùng chẳng gặp sự cố nào. Đó là lý do tester thiết kế test case để kích hoạt được nhiều nhánh nhất, buộc defect ẩn phải lộ ra thành failure mà ta quan sát được.

Và đừng nhầm việc của ai: tester report failure và truy về defect; còn việc lần ngược tiếp về error rồi sửa code (debugging, fixing) là phần của lập trình viên. Hiểu đúng chuỗi này giúp cả nhóm nói chung một ngôn ngữ. Nếu bạn muốn nắm trọn bộ thuật ngữ nền tảng theo chuẩn quốc tế, tham khảo bài ISTQB là gì để biết bức tranh chứng chỉ CTFL.