QA trong thời đại AI: Đừng chỉ kiểm tra hệ thống hoạt động, hãy tìm cách làm nó thất bại.
AI đang thay đổi cách phần mềm được xây dựng. Những tính năng trước đây cần nhiều giờ hoặc nhiều ngày để triển khai nay có thể được tạo ra chỉ sau vài câu lệnh. Nhưng khi tốc độ viết mã tăng lên, một vấn đề khác cũng xuất hiện: mã được tạo nhanh hơn tốc độ mà đội ngũ có thể kiểm thử và xác minh.
Trong bối cảnh đó, vai trò của QA không biến mất. Ngược lại, QA cần trở nên chủ động và đối kháng hơn: không chỉ kiểm tra hệ thống có hoạt động theo kịch bản dự kiến hay không, mà còn phải tìm cách đẩy hệ thống vào những trạng thái mà người viết mã — dù là con người hay AI — có thể chưa lường trước.
AI đang viết bao nhiêu phần trăm mã nguồn?
Không có một con số duy nhất cho câu hỏi này, bởi các nghiên cứu sử dụng những cách đo khác nhau. Một số khảo sát đo tỷ lệ mã có AI hỗ trợ, trong khi các nghiên cứu khác chỉ tính phần mã được AI tạo ra hoàn toàn hoặc đã được đưa vào production.
Theo khảo sát State of Code 2026 của Sonar với hơn 1.100 lập trình viên chuyên nghiệp, người tham gia cho biết AI hiện góp phần vào khoảng 42% số mã được commit. Con số này được dự đoán có thể tăng lên 65% vào năm 2027. Tuy nhiên, 96% lập trình viên cho biết họ chưa hoàn toàn tin tưởng mã do AI tạo ra và chỉ 48% luôn xác minh mã trước khi commit.
Một khảo sát khác của Fastly với 791 lập trình viên chuyên nghiệp cho thấy 32% senior developer cho biết hơn một nửa lượng mã họ đưa vào sản phẩm được AI tạo ra.
Trong khi đó, một phân tích trên hàng triệu developer ước tính tỷ lệ mã do AI tạo ra thực sự trong production thấp hơn, khoảng 26,9%. Sự khác biệt này cho thấy cần phân biệt rõ giữa “AI-assisted code” và “AI-authored code”.
Dù sử dụng cách đo nào, xu hướng chung vẫn rất rõ ràng: AI đang tham gia ngày càng sâu vào quá trình viết phần mềm.
Và điều đó tạo ra một câu hỏi quan trọng hơn:
Nếu AI viết ngày càng nhiều mã nguồn, ai sẽ tìm ra những trường hợp mà AI chưa nghĩ đến?
AI thường giải quyết mục tiêu, không phải toàn bộ thế giới thực
Một AI coding agent thường được giao một mục tiêu cụ thể:
- Tạo một màn hình.
- Thêm một API.
- Xây dựng chức năng upload.
- Thêm tính năng thanh toán.
- Sửa một lỗi trong repository.
- Viết test cho một module.
AI có thể hoàn thành yêu cầu đó rất nhanh. Nhưng “hoàn thành yêu cầu” không đồng nghĩa với “bao phủ toàn bộ cách người dùng có thể sử dụng hệ thống”.
Một luồng được AI tạo ra có thể hoạt động tốt như sau:
Mở màn hình → Nhập dữ liệu hợp lệ → Nhấn Submit một lần → Chờ phản hồi → Nhận thông báo thành công
Đây là happy path — luồng sử dụng lý tưởng mà người phát triển thường mô tả trong yêu cầu.
Nhưng người dùng thực tế có thể:
- Nhấn Submit hai hoặc ba lần liên tiếp.
- Refresh trang khi request đang xử lý.
- Mở cùng bản ghi trên nhiều tab.
- Gửi lại request sau khi mạng bị gián đoạn.
- Thao tác với dữ liệu đã bị xóa ở một tab khác.
- Tiếp tục sử dụng giao diện sau khi quyền truy cập đã thay đổi.
- Gửi dữ liệu ở giới hạn tối thiểu hoặc tối đa.
- Kết hợp nhiều tính năng theo một thứ tự không được dự kiến.
Một phân tích về khủng hoảng coverage trong QA cho mã do AI tạo ra cũng chỉ ra rằng các implementation do AI sinh thường tập trung vào kịch bản phổ biến, nhưng dễ bỏ sót điều kiện biên, biến thể hành vi người dùng và các ngoại lệ trong workflow.
Đây chính là khoảng trống mà kiểm thử truyền thống, nếu chỉ tập trung vào happy path, rất dễ bỏ qua.
Khi test đều xanh nhưng sản phẩm vẫn có thể thất bại
Một bộ test có thể chạy thành công vì nó đang kiểm tra chính xác những tình huống mà người viết mã đã nghĩ tới. Nếu cả code và test đều được tạo từ cùng một mô tả giới hạn, chúng có thể cùng bỏ qua một nhóm vấn đề.
Ví dụ, một tính năng xóa có thể vượt qua các test cơ bản:
Mở bản ghi → Nhấn Delete → Xác nhận → Bản ghi biến mất
Nhưng điều gì xảy ra trong các trường hợp sau?
Nhấn Delete hai lần cùng lúc Xóa ở Tab A trong khi Tab B đang chỉnh sửa Xóa bản ghi rồi submit form cũ Retry sau khi request timeout Xóa trong lúc một background job đang xử lý
Một hướng dẫn kiểm thử mã do AI tạo ra khuyến nghị phải kiểm tra cả giá trị biên, contract của API, lỗi tích hợp và các input đối kháng như duplicate submit, timeout, JSON không hợp lệ hoặc thanh toán bị từ chối.
Vì vậy, trạng thái “test pass” chỉ cho thấy hệ thống vượt qua những tình huống đã được kiểm tra. Nó không chứng minh rằng hệ thống sẽ an toàn trước mọi cách sử dụng thực tế.
QA cần chuyển từ kiểm tra sang đối kháng
Edsger Dijkstra từng nói:
“Program testing can be used to show the presence of bugs, but never to show their absence!”
Kiểm thử có thể cho thấy sự tồn tại của lỗi, nhưng không thể chứng minh phần mềm hoàn toàn không có lỗi.
Trong thời đại AI, câu nói này càng đáng được nhắc lại. Khi AI giúp tạo mã nhanh hơn, QA không nên chỉ cố chạy thêm thật nhiều test giống nhau. QA cần thay đổi câu hỏi:
- Không chỉ hỏi: “Luồng này có chạy đúng không?”
- Mà phải hỏi: “Tôi có thể làm luồng này thất bại bằng cách nào?”
Đó là tư duy của Adversarial Testing.
Adversarial Testing không có nghĩa là kiểm thử ngẫu nhiên hoặc cố tình phá hệ thống một cách thiếu kiểm soát. Đây là phương pháp kiểm thử có hệ thống, trong đó QA chủ động đóng vai:
- người dùng thiếu kiên nhẫn,
- người dùng thao tác sai,
- người dùng mở nhiều tab,
- nhiều người dùng cùng lúc,
- mạng không ổn định,
- request hoàn thành không đúng thứ tự,
- hoặc một actor cố tình đẩy hệ thống vào trạng thái bất thường.
Những câu hỏi QA cần đặt ra
Với mỗi tính năng, QA nên bắt đầu bằng những câu hỏi như:
- Điều gì xảy ra nếu người dùng lặp lại thao tác này?
- Điều gì xảy ra nếu thao tác bị ngắt giữa chừng?
- Điều gì xảy ra nếu hai request chạy đồng thời?
- Điều gì xảy ra nếu hai tab có trạng thái khác nhau?
- Điều gì xảy ra nếu dữ liệu bị thay đổi bởi một user khác?
- Điều gì xảy ra nếu request thành công nhưng UI nghĩ là thất bại?
- Điều gì xảy ra nếu UI hiển thị thành công nhưng backend thực tế thất bại?
- Điều gì xảy ra nếu request cũ hoàn thành sau request mới?
- Điều gì xảy ra nếu quyền truy cập thay đổi giữa lúc mở form và lúc submit?
- Trạng thái nào phải luôn đúng, bất kể người dùng thao tác như thế nào?
Những câu hỏi này giúp QA kiểm tra các nhóm rủi ro thường bị bỏ qua:
- duplicate action,
- race condition,
- stale state,
- multi-tab conflict,
- out-of-order response,
- network failure,
- retry behavior,
- input boundary,
- authorization change,
- cross-feature interaction,
- data integrity,
- và partial completion.
Một ví dụ đơn giản
Giả sử hệ thống có chức năng upload file.
Happy path:
Chọn file → Upload hoàn tất → Lưu file ID vào database → Hiển thị file trên giao diện
Adversarial Testing sẽ mở rộng thành:
Upload cùng một file hai lần Upload từ hai tab cùng lúc Refresh trong khi upload Đóng modal khi upload đang chạy Submit form trước khi upload hoàn tất Retry sau khi timeout Xóa file trong lúc background job đang xử lý Upload file có phần mở rộng đúng nhưng content type sai
Sau đó, QA cần kiểm tra các invariant:
- Không có file mồ côi trong storage.
- Không có database record trỏ tới file không tồn tại.
- Không tạo duplicate record ngoài chủ đích.
- UI không hiển thị upload thành công khi backend thất bại.
- Retry không tạo thêm side effect không mong muốn.
Đây là điểm khác biệt giữa việc “kiểm tra upload hoạt động” và “kiểm tra upload có thể thất bại như thế nào”.
Từ AI-generated code đến Adversarial Testing
AI giúp developer viết code nhanh hơn, nhưng tốc độ sinh mã không đảm bảo độ bao phủ của sản phẩm. Khi phần lớn code được tạo để giải quyết mục tiêu cụ thể, QA cần tìm ra những gì chưa được mô tả trong mục tiêu đó.
Các hướng kiểm thử quan trọng gồm:
Lặp lại
- Click nhanh nhiều lần.
- Gửi form liên tục.
- Retry sau timeout.
- Refresh rồi thực hiện lại thao tác.
Gián đoạn
- Mất mạng.
- Đóng tab.
- Điều hướng sang trang khác.
- Đăng xuất giữa request.
- Xóa entity liên quan khi xử lý đang diễn ra.
Song song
- Hai tab cùng chỉnh sửa.
- Hai user cùng cập nhật.
- Hai request delete chạy đồng thời.
- Request mới hoàn thành trước request cũ.
Trạng thái cũ
- Submit form đã mở từ trước.
- Dùng dữ liệu sau khi quyền đã bị thu hồi.
- Thao tác với record đã bị xóa ở nơi khác.
- Ghi đè dữ liệu mới bằng dữ liệu cũ.
Tương tác liên tính năng
- Upload và submit form.
- Xóa dữ liệu trong khi background job đang chạy.
- Thay đổi permission trong lúc một màn hình khác đang mở.
- Xóa file trong khi profile vẫn đang tham chiếu tới file đó.
Vai trò mới của QA
Trong quy trình phát triển truyền thống, QA thường được nhìn nhận như lớp kiểm tra sau khi developer hoàn thành chức năng. Trong quy trình có AI, cách tiếp cận này cần thay đổi.
AI có thể tạo ra code, test, tài liệu và thậm chí đề xuất cách sửa lỗi. Vì vậy, QA cần tập trung nhiều hơn vào những việc đòi hỏi tư duy độc lập:
- Xác định những giả định ẩn trong implementation.
- Tìm các trạng thái mà requirement chưa mô tả.
- Kiểm tra tương tác giữa nhiều actor và nhiều session.
- Phát hiện các lỗi chỉ xuất hiện khi request chạy song song.
- Xác minh invariant và tính toàn vẹn dữ liệu.
- Thiết kế các cuộc tấn công mà happy-path test không bao phủ.
QA không còn chỉ là người hỏi “Tính năng này có hoạt động đúng không?”. QA trở thành người hỏi:
“Hệ thống này sẽ thất bại ở đâu, trong điều kiện nào, và hậu quả sẽ là gì?”
Kết luận
AI đang giúp phần mềm được xây dựng nhanh hơn. Nhưng code được tạo nhanh không đồng nghĩa với việc sản phẩm đã sẵn sàng cho mọi tình huống thực tế.
Các khảo sát hiện nay cho thấy AI đã tham gia vào một tỷ lệ đáng kể mã nguồn được commit, trong khi nhiều developer vẫn không hoàn toàn tin tưởng output và cần xác minh trước khi đưa vào sản phẩm.
Phần lớn AI-generated code có thể hoàn thành happy path hoặc mục tiêu được mô tả. Nhưng người dùng thật không chỉ đi theo happy path. Họ lặp lại, gián đoạn, thao tác song song, sử dụng dữ liệu cũ và kết hợp nhiều tính năng theo những cách không phải lúc nào cũng xuất hiện trong yêu cầu ban đầu.
Vì vậy, QA trong thời đại AI cần chuyển từ việc chỉ xác nhận hệ thống hoạt động sang chủ động tìm cách làm nó thất bại.
Không chỉ kiểm tra:
“Hệ thống có chạy không?”
Mà phải hỏi:
“Nếu muốn phá vỡ hệ thống này mà không sửa mã nguồn, tôi sẽ thử điều gì tiếp theo?”
Tôi đang sử dụng một bộ skill để hỗ trợ quá trình Adversarial Testing và Bug Hunting theo cách có hệ thống hơn. Nếu bài viết này nhận được nhiều sự quan tâm, tôi sẽ chia sẻ bộ skill đầy đủ mà mình đang dùng.
Tài liệu tham khảo
1.State of Code Developer Survey report: The current reality of AI coding
2.Senior developers let AI do more of the coding — survey
3.More than 30% of code written in 2026 is generated by AI tools.4.AI-Generated Code Is Creating a QA Coverage Crisis in Enterprise SaaS