#Quy trình dùng AI trong kiểm thử: vòng lặp 4 bước và điểm kiểm chứng
Tóm tắt: Đưa AI vào kiểm thử thất bại khi thiếu quy trình, không phải khi thiếu công cụ. Vòng lặp bốn bước — lập kế hoạch, viết, gỡ lỗi, rà soát — đặt một điểm kiểm chứng của con người sau mỗi bước. Nguyên tắc phân việc: giao cho AI phần xác định được, giữ lại phần cần phán đoán.
Mục lục
- Vì sao đưa AI vào QA thường thất bại?
- Việc nào giao cho AI, việc nào giữ lại?
- Vòng lặp bốn bước và điểm kiểm chứng
- Vì sao mỗi bước đều cần điểm kiểm chứng?
- Bốn sai lầm khi triển khai vòng lặp
- Khi nào vòng lặp này không phù hợp?
- Câu hỏi thường gặp
#1. Vì sao đưa AI vào QA thường thất bại?
Phần lớn thất bại khi đưa AI vào kiểm thử không đến từ chất lượng mô hình, mà đến từ việc không ai định nghĩa AI được phép quyết định đến đâu.
Mẫu hình lặp lại thường như sau. Đội bắt đầu bằng một công cụ sinh test case. Kết quả ban đầu ấn tượng: hàng trăm kịch bản trong vài phút. Sau vài tuần, bộ test phình lên, không ai dám xoá vì không biết cái nào còn giá trị, và tỉ lệ lỗi lọt ra production không giảm. Đội kết luận "AI chưa đủ tốt cho QA" rồi quay lại cách cũ.
Chẩn đoán đúng hơn: công cụ được đưa vào một quy trình chưa có chỗ dành cho nó. Không có bước nào quy định ai xác nhận đầu ra, xác nhận dựa trên tiêu chí gì, và điều gì xảy ra khi đầu ra sai. Khi thiếu những quy định đó, mọi thứ AI tạo ra đều mặc nhiên được chấp nhận — kể cả phần sai.
Bài viết này mô tả một quy trình tối thiểu để tránh tình trạng đó. Nếu bạn quan tâm tới câu hỏi rộng hơn — vai trò kỹ sư QA thay đổi thế nào trong giai đoạn 2026–2030 — chúng tôi đã bàn riêng trong bài kỷ nguyên mới của QA trong thời đại AI.
#2. Việc nào giao cho AI, việc nào giữ lại?
Ranh giới hữu ích nhất không phải "việc dễ và việc khó", mà là việc xác định được và việc cần phán đoán.
Việc xác định được có tiêu chí đúng/sai rõ ràng, phạm vi hẹp, và kiểm chứng được ngay: sinh dữ liệu mẫu, chuyển đặc tả thành khung test case, tìm mẫu lặp trong log lỗi, chuẩn hoá tên biến theo quy ước. Việc cần phán đoán không có đáp án đúng duy nhất: có nên phát hành bản này không, rủi ro nào đáng chấp nhận, phạm vi nào đáng kiểm thử với nguồn lực đang có.
| Việc xác định được | Việc cần phán đoán | |
|---|---|---|
| Đặc điểm | Phạm vi hẹp, tiêu chí rõ | Nhiều đánh đổi, phụ thuộc bối cảnh |
| Ví dụ trong QA | Sinh dữ liệu mẫu, dựng khung test case, phân loại log lỗi | Quyết định phát hành, chọn phạm vi kiểm thử, đánh giá rủi ro nghiệp vụ |
| Ai làm chính | AI | Con người |
| Vai trò còn lại | Con người kiểm chứng | AI cung cấp dữ liệu đầu vào |
| Hậu quả khi giao nhầm | Lãng phí thời gian người | Rủi ro lọt lỗi nghiêm trọng |
Ranh giới này đang dịch chuyển, nhưng dịch chuyển chậm hơn nhiều so với cảm nhận thông thường. Nghiên cứu của METR (Measuring AI Ability to Complete Long Software Tasks, Kwa và cộng sự, NeurIPS 2025) đo năng lực mô hình bằng "chân trời thời gian 50%" — độ dài công việc mà con người thường mất bấy nhiêu thời gian, và mô hình hoàn thành được với tỉ lệ thành công 50%. Kết quả: chỉ số này tăng gấp đôi khoảng mỗi bảy tháng kể từ 2019.
Hai hệ quả thực tế. Thứ nhất, các tác vụ ngắn đang nhanh chóng rơi vào vùng AI làm tốt — nên giao đi sớm. Thứ hai, tác vụ càng dài và càng nhiều bước, tỉ lệ hoàn thành càng giảm — nên chia nhỏ trước khi giao, thay vì kỳ vọng AI xử lý trọn một luồng phức tạp.
#3. Vòng lặp bốn bước và điểm kiểm chứng
Vòng lặp dưới đây giữ AI ở vai trò thực thi trong từng bước hẹp, và đặt con người ở vị trí quyết định giữa các bước.
| Bước | AI làm gì | Con người kiểm chứng gì | Dấu hiệu cần dừng lại |
|---|---|---|---|
| 1. Lập kế hoạch | Đề xuất phạm vi kiểm thử từ đặc tả và mã nguồn | Phạm vi có khớp rủi ro nghiệp vụ thật không; thiếu vùng nào | Đề xuất chỉ bám đặc tả, không nhắc tới luồng ngoại lệ |
| 2. Viết | Sinh test case theo quy ước sẵn có của đội | Test case có kiểm tra đúng hành vi, hay chỉ kiểm tra lại chính đặc tả | Nhiều test khẳng định điều hiển nhiên đúng |
| 3. Gỡ lỗi | Phân loại lỗi, tìm mẫu lặp, đề xuất nguyên nhân | Nguyên nhân có được xác nhận bằng bằng chứng, hay chỉ là suy đoán hợp lý | Giải thích trôi chảy nhưng không dẫn được log cụ thể |
| 4. Rà soát | Đánh giá lại bộ test bằng một ngữ cảnh mới, độc lập | Phần bị bỏ sót ở ba bước trước | Vòng rà soát đồng ý hoàn toàn với vòng viết |
Bước 4 là bước hay bị cắt nhất, và cũng là bước đáng giữ nhất. Điểm mấu chốt: dùng ngữ cảnh mới — không tiếp tục phiên làm việc đã sinh ra bộ test. Mô hình đang mang theo lập luận cũ sẽ có xu hướng bảo vệ kết quả cũ. Ngữ cảnh sạch đóng vai trò như người rà soát chưa đọc bản nháp.
Dấu hiệu ở cột cuối đáng chú ý riêng: khi vòng rà soát đồng ý hoàn toàn với vòng viết, đó không phải bằng chứng bộ test tốt. Thường là dấu hiệu hai vòng đang chia sẻ cùng một giả định sai.
#4. Vì sao mỗi bước đều cần điểm kiểm chứng?
Vì độ tự tin của đầu ra không phản ánh độ chính xác của nó. Một mô hình trình bày kết quả sai với cùng giọng điệu chắc chắn như khi trình bày kết quả đúng — không có tín hiệu bề mặt nào để phân biệt.
Điều khiến vấn đề này khó xử lý hơn: chính người dùng có xu hướng giảm mức kiểm tra khi tin tưởng công cụ. Nghiên cứu của Microsoft Research và Carnegie Mellon University khảo sát 319 người lao động tri thức với 936 tình huống sử dụng AI thực tế (Lee và cộng sự, CHI 2025) cho thấy hai yếu tố dự báo mức độ tư duy phản biện: càng tin công cụ, mức kiểm chứng càng giảm; càng tự tin vào chuyên môn của chính mình, mức kiểm chứng càng tăng.
Với QA, hệ quả rất cụ thể. Người kiểm chứng đầu ra AI cần đủ chuyên môn nghiệp vụ để dám phản biện. Giao việc rà soát cho người mới — với lý do "đã có AI làm phần khó" — là đảo ngược đúng thứ tự cần thiết. Đây cũng là lý do vòng lặp này không giảm được yêu cầu về năng lực đội, mà chuyển yêu cầu đó sang chỗ khác.
#5. Bốn sai lầm khi triển khai vòng lặp
- Bỏ bước rà soát để tiết kiệm thời gian. Đây là bước duy nhất phát hiện lỗi hệ thống của ba bước trước. Bỏ nó đi thì vòng lặp trở thành đường thẳng.
- Dùng lại phiên làm việc cũ cho bước rà soát. Mô hình mang theo lập luận đã đưa ra sẽ bảo vệ kết luận đã đưa ra. Phải mở ngữ cảnh mới.
- Đo bằng số lượng test case sinh ra. Chỉ số này tăng dễ và không nói lên chất lượng. Đo tỉ lệ lỗi lọt ra production và tỉ lệ test case bị loại khi người rà lại.
- Giao vòng lặp cho người chưa nắm nghiệp vụ. Theo nghiên cứu ở mục 4, người càng ít tự tin về chuyên môn càng ít phản biện đầu ra AI — đúng điều vòng lặp cần tránh.
#6. Khi nào vòng lặp này không phù hợp?
- Dự án quá nhỏ. Nếu toàn bộ phạm vi kiểm thử gói trong vài ngày công, chi phí vận hành bốn bước lớn hơn lợi ích.
- Đặc tả đang thay đổi từng ngày. Bước 1 sẽ liên tục cho ra phạm vi lệch. Ổn định yêu cầu trước, áp quy trình sau.
- Hệ thống đòi trách nhiệm pháp lý tuyệt đối. Y tế, hàng không, lõi tài chính — nơi mọi quyết định phải truy được về một con người xác định. Vòng lặp vẫn dùng được ở bước 1 và 3, nhưng không nên dùng ở bước 2 và 4.
- Đội chưa có quy ước kiểm thử thành văn. AI sinh test theo quy ước sẵn có. Không có quy ước thì đầu ra sẽ không nhất quán giữa các lần chạy.
#7. Câu hỏi thường gặp
Bắt đầu áp dụng vòng lặp này từ đâu cho ít rủi ro nhất? Chọn một module có phạm vi hẹp, đã ổn định về yêu cầu, và có bộ test cũ để đối chiếu. Chạy song song vòng lặp với cách làm hiện tại trong hai đến ba tuần, so sánh số lỗi phát hiện được và thời gian bỏ ra. Có số liệu đối chiếu rồi mới mở rộng phạm vi.
Vòng lặp này cần công cụ gì đặc biệt không? Không. Jira, TestRail, Selenium giữ nguyên vai trò lưu trữ và thực thi. Thay đổi nằm ở lớp phía trước: cách sinh, rà soát và duy trì kịch bản. Yêu cầu bắt buộc duy nhất là công cụ AI cho phép mở ngữ cảnh mới hoàn toàn cho bước 4.
Làm sao biết bước rà soát đang thực sự có tác dụng? Theo dõi tỉ lệ phát hiện của riêng bước 4: trong số vấn đề tìm được mỗi vòng, bao nhiêu phần trăm đến từ bước rà soát. Nếu tỉ lệ này gần bằng không qua nhiều vòng, khả năng cao bước 4 đang dùng lại ngữ cảnh cũ hoặc tiêu chí rà soát chưa đủ khác biệt.
Áp dụng vòng lặp có giảm được số lượng nhân sự QA không? Không nên đặt kỳ vọng đó. Vòng lặp giảm thời gian cho phần việc xác định được, nhưng tăng yêu cầu về năng lực nghiệp vụ ở phần kiểm chứng. Hiệu quả thường thể hiện ở tốc độ có bộ test chạy được và ở số lỗi phát hiện sớm, không ở số người.
Dữ liệu dự án đưa cho AI có an toàn không? Cần xử lý ở mức quy trình, không chỉ mức công cụ. Dùng mô hình triển khai tại chỗ hoặc dịch vụ doanh nghiệp có cam kết hợp đồng không dùng dữ liệu khách hàng để huấn luyện mô hình chung, kèm quy định phân loại tài liệu: loại nào được đưa ra công cụ ngoài, loại nào không.
#Kết & bước tiếp theo
Giá trị của AI trong kiểm thử nằm ở chỗ nó rút ngắn phần việc xác định được, chứ không phải ở chỗ nó thay con người quyết định. Vòng lặp bốn bước tồn tại để giữ đúng ranh giới đó: AI thực thi trong phạm vi hẹp, con người quyết định giữa các bước, và mỗi bước đều để lại một chỗ để phát hiện sai sót trước khi nó đi tiếp.
Nếu đội của bạn đang cân nhắc đưa AI vào quy trình kiểm thử, bước hợp lý đầu tiên là xác định hiện trạng: quy ước kiểm thử đã thành văn chưa, phần nào đang là việc xác định được, phần nào cần giữ lại cho con người. VAON cung cấp dịch vụ Audit quy trình QA và kiến trúc hệ thống miễn phí, dựa trên kinh nghiệm phát triển hệ thống và tư vấn chuyển đổi số cho doanh nghiệp Nhật Bản.
Nguồn tham khảo
- Thomas Kwa và cộng sự. Measuring AI Ability to Complete Long Software Tasks. arXiv:2503.14499, NeurIPS 2025. https://arxiv.org/abs/2503.14499
- Hao-Ping Lee và cộng sự. The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. CHI 2025. https://dl.acm.org/doi/full/10.1145/3706598.3713778
- David Ingraham. The Most Valuable QA Skill in the Age of AI Is Thinking. DEV Community. https://dev.to/cydavid/the-most-valuable-qa-skill-in-the-age-of-ai-is-thinking-3b8p