AI trong kiểm thử phần mềm năm 2026: hướng dẫn thực hành cho QA

1. Xác định vai trò AI trước khi viết prompt

LLM dự đoán văn bản; nó không quan sát môi trường test và không biết phiên bản yêu cầu mới nhất. Hãy giao một nhiệm vụ giới hạn: thu thập câu hỏi cho BA, đề xuất lớp dữ liệu, giải thích code, tạo SQL nháp hoặc phản biện bộ test hiện có. “Hãy test form này” quá rộng và thường chỉ tạo checklist chung có vẻ hợp lý.

Trước tiên hãy ghi oracle: acceptance criterion, OpenAPI, quy tắc tính toán, schema database hoặc quyết định sản phẩm. Khi chưa có oracle, mô hình không được tự tạo expected behavior; đầu ra nên là câu hỏi và rủi ro cần con người quyết định.

• Mục tiêu: quyết định nào cần đưa ra?
• Ngữ cảnh: quy tắc nào đã biết?
• Giới hạn: mô hình không thể xác nhận gì?
• Định dạng: bảng, danh sách, SQL hay test case?
• Kiểm chứng: nguồn hoặc lần chạy nào chứng minh kết quả?

2. Cung cấp ngữ cảnh, ràng buộc và định dạng đầu ra

Prompt tốt giống một task giao cho đồng nghiệp. Nêu hệ thống, role người dùng, business rule, input, state đã biết và định dạng cần nhận. Yêu cầu mô hình tách fact khỏi assumption và liệt kê thông tin thiếu. Cách này giảm nội dung chung chung và giúp review được.

Không nên yêu cầu một trăm test ngay. Trước hết hãy hỏi về rủi ro và equivalence class, sau đó mở rộng nhánh quan trọng. Với chức năng phức tạp, dùng hai lượt: generator đề xuất bộ test, critic tìm trùng lặp, lỗ hổng và expected không có căn cứ. Con người vẫn duyệt kết quả cuối.

Bối cảnh: CRM. Manager chuyển lead thành customer.
Đã biết: email customer là duy nhất; request có thể retry sau timeout.
Nhiệm vụ: tạo bảng rủi ro và test idea.
Mỗi dòng gồm condition, action, observable result, nguồn oracle.
Không tự tạo rule. Đưa thông tin thiếu vào mục Questions.

3. Dùng AI cho test design, không phải để tăng số lượng

Mô hình hữu ích khi parameter và rule rõ ràng: biên quantity, order state, role và payment method. Hãy yêu cầu equivalence class, decision table hoặc state model trước khi tạo test case. Khi đó bạn thấy logic rút gọn thay vì nhận hai mươi câu gần giống nhau.

Tự kiểm tra coverage. Giá trị phải bao quanh cả hai biên, state test phải có transition hợp lệ và bị cấm, còn pairwise phải thật sự phủ các cặp. Cẩn thận với giá trị mô hình gọi là “hiển nhiên” vì nó có thể mượn quy ước từ sản phẩm khác.

Parameters: role={manager,lead}; status={new,won,lost}; action={view,edit,convert}.
Tạo decision table và đánh dấu tổ hợp bị cấm.
Sau đó đề xuất bộ test tối thiểu và nêu rule được phủ bởi từng test.

4. Chạy API, SQL và automation artifact do AI tạo

Code nhìn hợp lý có thể gọi cột không tồn tại, biến LEFT JOIN thành INNER JOIN hoặc chỉ assert status 200. Hãy cung cấp schema và contract tối thiểu trước khi tạo. Sau đó đọc query, chạy với dữ liệu kiểm soát và tính expected trước. Dùng database test và transaction cho SQL thay đổi dữ liệu.

Với automation, kiểm tra locator, wait, cleanup và diagnostic artifact. AI thường viết sleep cố định, chuỗi test phụ thuộc và CSS selector dễ vỡ. Test hữu ích phải ổn định qua nhiều lần chạy, fail đúng lý do khi cố tình tạo lỗi và để lại trace, request hoặc screenshot.

-- Dự đoán trước: customer 3 và 4
SELECT c.id
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL
ORDER BY c.id;
-- Thêm order cho customer 3 và chỉ còn customer 4

5. Không đưa secret và dữ liệu người dùng vào prompt

Production log, token, cookie, private URL, dữ liệu cá nhân và code nội bộ có thể vi phạm chính sách hoặc hợp đồng. Hãy giảm context: thay tên và email bằng dữ liệu synthetic, che credential và chỉ giữ field request/response cần thiết. Xóa tên chưa đủ nếu các field còn lại vẫn nhận diện được người.

Xác nhận model và mode nào được phép, dữ liệu lưu thế nào và có thể tắt training hay không. Đôi khi lựa chọn an toàn là ví dụ synthetic cục bộ thay vì prompt chứa source data. Instruction nằm trong log và document cũng là input không đáng tin vì prompt injection có thể đi qua chúng.

• Đã xóa Bearer token, cookie và API key.
• PII đã thay bằng dữ liệu synthetic.
• Địa chỉ và identifier nội bộ đã khái quát.
• Chỉ chia sẻ đoạn tối thiểu, không gửi dump.
• Việc dùng model tuân thủ policy của team.

6. Chấm đầu ra bằng rubric và lưu provenance

Với công việc lặp lại, dùng rubric gồm correctness theo nguồn, risk coverage, không bịa, khả năng chạy, safety và diagnostics. “Trông ổn” không phát hiện status code sai hay thiếu authorization boundary. Điểm còn tranh luận phải được đánh dấu để hỏi, không biến thành test với expected tự tạo.

Lưu phiên bản yêu cầu, prompt quan trọng, tool hoặc model, ngày, kết quả đã chỉnh và cách kiểm chứng. Nhờ vậy có thể bảo trì test sau khi sản phẩm đổi. Không xuất bản raw AI text thành tài liệu team khi chưa có owner và review.

Correctness: mỗi expected có nguồn oracle
Coverage: role, state, boundary, integration, error
Evidence: action chạy được, result quan sát được
Safety: không có secret hoặc PII
Maintainability: không trùng, data và priority rõ

7. Đưa AI vào team bằng experiment nhỏ và đo được

Không bắt đầu bằng “mọi task đều dùng AI”. Chọn một process lặp lại như review acceptance criteria hoặc chuẩn bị API test idea. Lấy baseline không AI: thời gian, số câu hỏi hữu ích và lỗi sau review. Sau đó chạy nhiều vòng với một template và cùng quality rubric.

Ghi rõ boundary: data được phép, ai approve output, provenance lưu ở đâu và khi nào phải dừng. Pilot thành công phải cải thiện kết quả đã kiểm chứng chứ không phải số dòng sinh ra. Team dùng evidence để chuẩn hóa, sửa hoặc kết thúc experiment.

Use case: review acceptance criteria
Baseline: 20 stories không AI
Pilot: 20 stories tương đương với một template
Metrics: review time, accepted questions, defects, leaks=0
Owner: QA lead; review: analyst
Decision date: sau 40 stories

8. Trình bày việc dùng AI trong phỏng vấn QA

Interviewer cần quy trình có kiểm soát, không phải danh sách tool. Chuẩn bị ví dụ gồm task, context đã làm sạch, draft, idea hữu ích, lỗi của model, cách bạn kiểm chứng và kết quả đo được. Khả năng phản biện LLM mạnh hơn câu “tôi tạo test case bằng ChatGPT”.

Hãy giải thích hallucination, kiến thức cũ, nondeterminism, rò rỉ dữ liệu, prompt injection và automation bias. Với Middle, thêm cơ chế team: prompt template, review rubric, evaluation case và rule cho công việc bị cấm hoặc cần reviewer thứ hai.