Khách bấm thanh toán, màn hình quay vòng rồi báo lỗi, trong khi tài khoản ngân hàng đã bị trừ tiền. Nhân viên chăm sóc khách hàng chuyển phản ánh cho đội kỹ thuật với một dòng “web bị bug”, và từ đó bắt đầu một chuỗi hỏi qua hỏi lại: lỗi ở đâu, trên máy nào, lặp lại được không. Bug là gì? Bug là khiếm khuyết trong phần mềm khiến nó chạy sai so với yêu cầu: tính sai một con số, hiện sai một màn hình, treo giữa chừng hoặc mở ra lỗ hổng cho người ngoài lợi dụng. Theo giáo trình kiểm thử của ISTQB, con người mắc lỗi (error), lỗi đó tạo ra khiếm khuyết (defect, còn gọi là bug hay fault), và khiếm khuyết khi được chạy tới thì gây ra sự cố (failure) mà người dùng nhìn thấy. Việc tìm ra bug gọi là debug, việc sửa gọi là fix bug, và cả hai đi nhanh hơn nhiều khi bug được ghi lại đúng cách ngay từ lúc phát hiện. Các định nghĩa và số liệu trong bài tra ngày 14/10/2026.
Bug là gì và từ này bắt nguồn từ đâu
Trong tiếng Anh, “bug” nghĩa đen là con bọ, và giới kỹ thuật đã dùng nó để chỉ trục trặc máy móc từ trước thời máy tính. Câu chuyện hay được kể nhất xảy ra ngày 09/09/1947 tại Đại học Harvard: nhóm vận hành máy tính rơ le Mark II tìm thấy một con bướm đêm kẹt giữa hai tiếp điểm của rơ le số 70, bảng F. Họ dán con bướm vào sổ nhật ký vận hành kèm dòng chú thích “First actual case of bug being found”, tức lần đầu tìm thấy một con bọ thật. Mô tả lưu trữ của Hải quân Mỹ đi kèm bức ảnh ghi rõ thuật ngữ “debugging” lúc đó đã tồn tại, nên việc gặp một con bọ thật mới thành chuyện vui để ghi lại.
Ngày nay bug là thuật ngữ chung của mọi người làm phần mềm, từ lập trình viên, kiểm thử viên (tester, QA) tới người quản lý dự án. Bug không chỉ nằm trong mã nguồn. Giáo trình ISTQB ghi khiếm khuyết còn nằm được trong tài liệu yêu cầu, kịch bản kiểm thử, hay tệp cấu hình build, và khiếm khuyết ở tài liệu làm sớm mà không ai phát hiện thường kéo theo khiếm khuyết ở các bước sau. Một bản đặc tả ghi nhầm cách làm tròn thuế, lập trình viên viết đúng theo bản đó, thì phần mềm vẫn tính sai dù từng dòng mã đều làm đúng việc được giao.
Lỗi, bug và sự cố khác nhau ở chỗ nào
Ba từ này hay bị dùng lẫn, nhưng mỗi từ chỉ một mắt xích khác nhau. Phân biệt được chúng giúp cuộc trao đổi giữa người báo lỗi và người sửa đi đúng chỗ ngay từ đầu. Giáo trình ISTQB Certified Tester Foundation Level, bản cập nhật ngày 15/09/2024 định nghĩa chuỗi này ở mục 1.2.3, và thêm một khái niệm thứ tư là nguyên nhân gốc (root cause).
| Thuật ngữ | Nghĩa | Ví dụ trong phần mềm bán hàng |
|---|---|---|
| Lỗi người làm (error, mistake) | Hành động sai của con người khi viết yêu cầu, thiết kế hay viết mã | Lập trình viên hiểu “giảm 10%” là giảm trên giá đã có thuế |
| Khiếm khuyết (defect, bug, fault) | Chỗ sai nằm lại trong sản phẩm | Dòng mã tính khuyến mãi sau bước cộng thuế |
| Sự cố (failure) | Hệ thống chạy sai khi khiếm khuyết được thực thi | Hoá đơn in ra lệch vài nghìn đồng so với bảng giá |
| Nguyên nhân gốc (root cause) | Lý do cơ bản dẫn tới lỗi người làm | Tài liệu yêu cầu không ghi thứ tự áp khuyến mãi và thuế |
Giáo trình cũng nêu hai điểm hay bị bỏ qua. Thứ nhất, có khiếm khuyết lần nào chạy tới cũng gây sự cố, có cái chỉ gây sự cố trong điều kiện đặc biệt, và có cái không bao giờ gây sự cố. Thứ hai, sự cố còn đến từ điều kiện môi trường như bức xạ hay từ trường làm hỏng firmware, tức là có trường hợp phần mềm chạy sai mà mã nguồn không có bug. Hiểu điều này thì đội kỹ thuật bớt mất công lục mã khi nguyên nhân thật nằm ở thiết bị hay mạng.
Bug phát sinh từ đâu trong quá trình làm phần mềm
ISTQB liệt kê các lý do khiến người làm phần mềm mắc lỗi: áp lực thời gian, độ phức tạp của sản phẩm, quy trình, hạ tầng hay các mối tương tác, hoặc đơn giản là mệt và thiếu đào tạo. Bài viết cũ chia nguyên nhân thành chín nhóm, và cả chín vẫn đúng khi đặt cạnh danh sách đó:
- Sơ suất của người viết mã: gõ nhầm tên biến, quên một trường hợp rỗng, so sánh sai kiểu dữ liệu. Không ai viết mã mà không sai lần nào, nên mọi sản phẩm cần kiểm thử từng phần và kiểm thử tổng thể trước khi phát hành.
- Hiểu sai yêu cầu: người viết mã làm theo cách hiểu của mình khi yêu cầu mơ hồ. Mã chạy đúng ý lập trình viên nhưng sai ý người đặt hàng, và cách sửa là làm rõ yêu cầu rồi viết lại phần đó.
- Thời hạn quá gấp: làm dồn để kịp ngày ra mắt thì bước rà soát và kiểm thử bị cắt trước tiên.
- Thiết kế khó hiện thực: luồng nghiệp vụ hoặc giao diện vượt khả năng kỹ thuật trong thời gian cho phép, cần trao đổi lại để chỉnh thiết kế hoặc lùi thời hạn.
- Mã viết thiếu cấu trúc: mã chắp vá, đặt tên lộn xộn, không có tài liệu khiến mỗi lần sửa một chỗ lại hỏng chỗ khác. Đội tiếp quản một bộ mã như vậy thường mất nhiều công hơn viết lại.
- Quản lý phiên bản build lộn xộn: một chức năng đã chạy đúng ở bản trước bỗng sai ở bản sau (bug hồi quy), và nếu không đánh số phiên bản nhất quán thì không biết bug sinh ra từ lần thay đổi nào.
- Kiểm thử sơ sài: kiểm thử thiếu kịch bản hoặc chỉ thử đường đi suôn sẻ thì bug lọt ra tay người dùng thật.
- Thư viện và công cụ bên thứ ba: thư viện có sẵn cũng có bug, và bản cập nhật của chúng có thể làm hỏng chức năng đang chạy, nên cần kiểm thử lại sau mỗi lần nâng cấp.
- Đổi thiết kế sát ngày phát hành: thay đổi phút chót không còn đủ thời gian viết lại, kiểm thử lại, nên là nguồn bug khó tránh nhất.
Giáo trình ISTQB nêu một nguyên tắc giải thích vì sao các nhóm nguyên nhân đầu danh sách đáng xử lý sớm: khiếm khuyết gỡ được ở giai đoạn đầu sẽ không sinh thêm khiếm khuyết ở các sản phẩm làm sau, nên chi phí chất lượng giảm. Một câu yêu cầu được sửa lúc còn trên giấy chỉ mất vài phút; cùng câu đó phát hiện sau khi phần mềm đã chạy với dữ liệu thật thì phải sửa mã, sửa dữ liệu và xin lỗi khách. Đó là lý do quy trình kiểm thử phần mềm bắt đầu từ khâu đọc yêu cầu, sớm hơn nhiều so với lúc có bản chạy thử.
Những loại bug thường gặp
Bài viết cũ phân loại bug theo cách nói vui: bug tí hon, bug khủng và bug ẩn thân. Đổi sang tên gọi chuẩn của nghề thì dễ tra cứu và dễ giao việc hơn. Bảng dưới gom các loại bug hay gặp trong phần mềm quản lý và website bán hàng.
| Loại bug | Biểu hiện | Thường lộ ra khi nào |
|---|---|---|
| Lỗi cú pháp | Thiếu dấu chấm phẩy, thiếu ngoặc, thụt lề sai; chương trình không biên dịch hoặc không chạy | Ngay lúc build, trình biên dịch báo dòng lỗi |
| Lỗi logic, tính toán | Chương trình chạy nhưng ra kết quả sai: cộng sai tồn kho, làm tròn sai tiền | Khi đối chiếu số liệu, thường do kế toán hay kho phát hiện |
| Lỗi chức năng | Nút bấm không làm đúng việc, luồng duyệt bỏ qua một bước | Kiểm thử chức năng hoặc khi người dùng thao tác |
| Lỗi hồi quy | Chức năng cũ đang đúng bỗng sai sau một lần cập nhật | Ngay sau khi phát hành bản mới |
| Lỗi hiệu năng | Trang chậm, báo cáo chạy hàng phút, hệ thống treo giờ cao điểm | Khi dữ liệu và lượng người dùng tăng |
| Lỗi tương thích | Chạy đúng trên Chrome nhưng vỡ giao diện trên Safari, lỗi trên một dòng điện thoại | Khi người dùng dùng thiết bị chưa được thử |
| Lỗ hổng bảo mật | Không hiện ra trên màn hình nhưng cho người ngoài đọc hoặc sửa dữ liệu | Khi bị tấn công, hoặc khi rà soát bảo mật |
Loại tốn công nhất là bug chỉ xuất hiện thỉnh thoảng, chẳng hạn hai người cùng bấm duyệt một đơn trong cùng một giây, hoặc lỗi chỉ xảy ra khi máy chủ chạy qua nửa đêm. Bài cũ kể chuyện lập trình viên mất cả ngày chỉ vì quên một dấu chấm phẩy; với công cụ biên dịch và trình soạn thảo hiện nay, lỗi cú pháp thường bị gạch đỏ ngay khi gõ, còn bug logic và bug chỉ xuất hiện theo điều kiện mới là phần chiếm thời gian. Giáo trình ISTQB cũng ghi rằng khiếm khuyết hay dồn cụm: một số ít thành phần chứa phần lớn khiếm khuyết, nên phân hệ nào đã có nhiều bug thì đáng kiểm thử kỹ hơn.
Có những báo lỗi rốt cuộc là yêu cầu thay đổi hoặc lỗi thiết bị
Bài viết cũ có một mục thú vị về những “bug” rốt cuộc lại là thứ khác, và giáo trình ISTQB xác nhận đúng chuyện đó: mục quản lý khiếm khuyết ghi rằng một báo lỗi khi xử lý có thể hoá ra là khiếm khuyết thật, hoặc là thứ khác như kết quả dương tính giả hay yêu cầu thay đổi. Ba trường hợp hay gặp nhất là phần mềm làm đúng đặc tả nhưng người dùng mong một cách khác, phần mềm đúng nhưng thiết bị của người dùng hỏng hoặc quá cũ, và kiểm thử viên đọc sai kết quả mong đợi.
Phân loại rõ ngay từ đầu có ý nghĩa với cả chi phí lẫn quan hệ hai bên. Một yêu cầu thay đổi đi theo quy trình báo giá và lên lịch, còn một bug thật trong phạm vi bảo hành thì bên làm phần mềm sửa. Khi hợp đồng và tài liệu đặc tả ghi rõ chức năng phải chạy thế nào, ranh giới này hiện ra ngay mà hai bên khỏi phải tranh luận. Bài phát triển phần mềm là gì và các mô hình phát triển mô tả nơi tài liệu đặc tả nằm trong từng mô hình.
Ghi lại bug thế nào để người sửa làm được ngay
Một báo lỗi chỉ ghi “trang thanh toán bị lỗi” buộc người sửa đi hỏi lại từ đầu. Theo ISTQB, báo cáo khiếm khuyết có ba mục tiêu: cho người xử lý đủ thông tin để giải quyết, giúp theo dõi chất lượng sản phẩm, và gợi ý cải tiến quy trình làm và kiểm thử. Báo cáo ghi trong lúc kiểm thử thường gồm mã định danh, tiêu đề tóm tắt, ngày phát hiện và người báo, đối tượng và môi trường kiểm thử, bối cảnh, mô tả cách tái hiện kèm log hay ảnh chụp, kết quả mong đợi và kết quả thực tế, mức độ nghiêm trọng, mức ưu tiên, trạng thái và tài liệu tham chiếu.
Bài viết cũ gợi ý ghi ngày phát hiện, triệu chứng kèm ảnh hoặc video, nguyên nhân sau khi sửa, và cách xử lý, rồi lưu thành bảng tính để người tiếp quản đọc lại. Ý đó vẫn dùng được; khác biệt là các công cụ quản lý bug như Jira, GitHub Issues hay GitLab Issues tự điền mã, ngày, người báo và trạng thái, nên người báo chỉ cần tập trung vào phần mô tả. Thứ tự ghi một báo cáo dùng được ngay:
- Đặt tiêu đề nói rõ chỗ sai và điều kiện, ví dụ “Đơn có mã giảm giá tính sai thuế khi thanh toán bằng QR”.
- Ghi môi trường: bản phần mềm, trình duyệt hoặc ứng dụng, thiết bị, tài khoản thử.
- Liệt kê từng bước thao tác theo thứ tự để người khác làm lại được đúng sự cố.
- Ghi kết quả mong đợi và kết quả thực tế, kèm ảnh chụp, video ngắn hoặc mã đơn cụ thể.
- Chọn mức nghiêm trọng (ảnh hưởng tới đâu) và để trưởng nhóm xếp mức ưu tiên (sửa trước hay sau).
- Sau khi sửa, ghi nguyên nhân gốc và cách sửa vào chính báo cáo đó, rồi kiểm thử lại trước khi đóng.
Mức nghiêm trọng và mức ưu tiên là hai trục khác nhau. Một lỗi chính tả trên trang chủ ít nghiêm trọng nhưng ưu tiên cao vì ai cũng thấy; một lỗi làm sai báo cáo năm rất nghiêm trọng nhưng nếu còn ba tháng mới tới kỳ chốt sổ thì xếp sau lỗi đang chặn khách thanh toán. Đội làm theo bảng Kanban thường đặt cột trạng thái bug giống danh sách ISTQB: mới mở, chờ sửa, chờ kiểm lại, mở lại, đóng.
Debug và fix bug diễn ra theo trình tự nào
Debug là quá trình tìm ra chỗ sai, fix bug là sửa nó, và giữa hai việc ấy là bước quan trọng nhất: tái hiện được sự cố. Lập trình viên bắt đầu bằng việc làm lại đúng các bước trong báo cáo trên môi trường thử, đọc log để biết chương trình đã đi qua đâu, rồi khoanh vùng tới hàm, tới dòng mã gây sai. Trình gỡ lỗi (debugger) trong Visual Studio, VS Code hay công cụ dành cho nhà phát triển của trình duyệt cho phép dừng chương trình ở một dòng và xem giá trị từng biến lúc đó.
Sửa xong một bug chưa phải là xong việc. Bản sửa cần một bài kiểm thử xác nhận rằng sự cố đã hết, và một vòng kiểm thử hồi quy để chắc chắn chỗ khác không hỏng theo. ISTQB nhắc hai nguyên tắc liên quan: kiểm thử chỉ chứng minh được bug đang có, chứ không chứng minh được phần mềm hết bug; và bộ kiểm thử lặp lại mãi sẽ “mòn”, ít bắt được bug mới, nên kịch bản và dữ liệu thử cần được bổ sung. Với hệ thống đang chạy thật, bản sửa nên đi kèm kế hoạch quay lại bản cũ và bản sao lưu dữ liệu trước khi cập nhật, vì bug trong bản sửa lỗi cũng là bug.
Một bug lọt ra ngoài tốn bao nhiêu
Con số được trích nhiều nhất về chi phí của bug là báo cáo do RTI thực hiện cho Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST), tháng 5/2002. Dựa trên khảo sát nhà phát triển và người dùng phần mềm, báo cáo ước tính hạ tầng kiểm thử phần mềm kém khiến nền kinh tế Mỹ tốn từ 22,2 tới 59,5 tỷ USD mỗi năm, và hơn một nửa chi phí đó do người dùng gánh, dưới dạng công sức phòng tránh và khắc phục lỗi. Số liệu đã cũ, nhưng cách chia chi phí vẫn đúng: phần lớn thiệt hại của bug rơi vào người dùng phần mềm, tức chính doanh nghiệp đặt làm.
Ví dụ gần đây và lớn nhất là sự cố tháng 7/2024, khi một bản cập nhật cấu hình lỗi của phần mềm bảo mật CrowdStrike làm hàng loạt máy Windows khởi động lại liên tục. Microsoft ước tính ngày 20/07/2024 sự cố ảnh hưởng 8,5 triệu thiết bị Windows, chưa tới 1% tổng số máy Windows, nhưng vì nằm ở các doanh nghiệp vận hành dịch vụ quan trọng nên tác động kinh tế và xã hội rất rộng.
Ở quy mô một doanh nghiệp, cái giá thường nhỏ hơn nhưng cụ thể hơn: một ngày bán hàng mất đơn vì nút thanh toán lỗi, một tháng lương tính sai phải làm lại, một kỳ báo cáo thuế lệch số. Phần mềm viết riêng cho doanh nghiệp chịu thêm một rủi ro mà phần mềm đóng gói ít gặp, là bug nằm đúng trong quy tắc nghiệp vụ đặc thù mà chỉ người trong ngành mới nhận ra. Vì vậy người dùng nghiệp vụ tham gia kiểm thử nghiệm thu là bước bắt buộc trước khi đưa hệ thống vào chạy.
Hỏi đáp
Bug là gì?
Bug là khiếm khuyết trong phần mềm khiến nó chạy sai so với yêu cầu, như tính sai số liệu, hiện sai màn hình, treo hoặc để lộ dữ liệu. Theo ISTQB, bug là tên gọi khác của defect và fault: lỗi của người làm tạo ra bug, và bug khi được chạy tới thì gây ra sự cố.
Debug và fix bug khác nhau thế nào?
Debug là tìm ra bug: tái hiện sự cố, đọc log, khoanh vùng tới dòng mã gây sai. Fix bug là sửa chỗ sai đó rồi kiểm thử lại. Hai việc thường do cùng một lập trình viên làm liền nhau.
Bug, error và failure khác nhau ra sao?
Error là sai lầm của con người khi viết yêu cầu hay viết mã. Bug, hay defect, là chỗ sai còn nằm lại trong sản phẩm. Failure là lúc hệ thống thật sự chạy sai trước mắt người dùng vì bug được thực thi.
Tại sao phần mềm đã kiểm thử kỹ vẫn còn bug?
Vì kiểm thử chỉ chứng minh được bug đang có, không chứng minh được phần mềm hết bug, và kiểm thử mọi trường hợp là bất khả thi trừ phần mềm rất nhỏ. Kiểm thử tốt giảm xác suất bug lọt ra ngoài và tập trung vào chỗ rủi ro cao nhất.
Báo một bug cần ghi những gì?
Tối thiểu cần tiêu đề rõ, môi trường (phiên bản, thiết bị, trình duyệt), các bước tái hiện, kết quả mong đợi và kết quả thực tế, ảnh chụp hoặc video, cùng mức nghiêm trọng. Có đủ những mục này thì người sửa bắt tay vào làm ngay, khỏi hỏi lại.
Lỗi do người dùng hiểu sai có tính là bug không?
Thường là không. Nếu phần mềm chạy đúng tài liệu đặc tả mà người dùng mong cách khác, đó là yêu cầu thay đổi; nếu thiết bị người dùng hỏng thì đó là lỗi môi trường. Quy trình quản lý khiếm khuyết của ISTQB có bước phân loại riêng cho các trường hợp này.
Bug không biến mất khỏi phần mềm, nhưng số bug lọt tới tay người dùng phụ thuộc rất nhiều vào cách làm: yêu cầu ghi rõ, kiểm thử bắt đầu sớm, mỗi bug được ghi lại và truy tới nguyên nhân gốc. MONA Software viết phần mềm theo yêu cầu với quy trình kiểm thử và nghiệm thu đi cùng từng phân hệ, kèm theo dõi vận hành sau bàn giao; xem dịch vụ viết phần mềm theo yêu cầu hoặc dịch vụ lập trình web app. Nếu hệ thống đang dùng phát sinh bug lặp lại mà đội cũ không còn hỗ trợ, gọi hotline 1900 636 648, mô tả lỗi theo các bước ở trên để được đánh giá nguyên nhân và hướng xử lý.
