1. Bối cảnh phỏng vấn: từ 'biết công cụ AI' đến 'có chiến lược AI'
Năm 2026, gần như ứng viên QA nào cũng nói được vài câu về agent sinh test hay self-heal. Điều khiến nhà tuyển dụng cấp senior chú ý không còn là bạn biết công cụ nào, mà là bạn có một chiến lược mạch lạc: AI nên đặt ở đâu, ở đâu tuyệt đối giữ con người, đo bằng chỉ số gì, và làm sao thuyết phục lãnh đạo bằng con số. Một buổi phỏng vấn chiến lược thường không hỏi 'viết một test' mà hỏi 'công ty tôi có ba nghìn test, 8% flaky, đội tám người, ngân sách token có hạn — anh phân bổ AI thế nào'. Đó là câu hỏi tư duy, không phải câu hỏi cú pháp.
Bài này viết cho góc phỏng vấn chuyên sâu: mỗi chương gắn với một câu hỏi lớn mà người phỏng vấn thật sự hỏi, kèm câu trả lời mẫu và phần 'người phỏng vấn tìm gì'. Xuyên suốt, ta bám một hệ chỉ số: độ phủ luồng (coverage), tỉ lệ lọt lỗi (escape rate), tỉ lệ flaky, tỉ lệ tự chữa (heal rate), điểm đánh giá (eval score), chi phí và độ trễ. Mục tiêu không phải học thuộc định nghĩa mà là biết đọc chúng thành bộ, cân bằng lẫn nhau, và ra quyết định phân bổ nguồn lực AI theo rủi ro nghiệp vụ.
Một điểm nữa cần nhớ trước khi bước vào phòng phỏng vấn: người phỏng vấn cấp cao thường không tìm một đáp án hoàn hảo mà tìm cách bạn tư duy dưới ràng buộc. Họ sẽ cố tình thêm ràng buộc — ngân sách bị cắt, đội mất người, deadline dồn — để xem bạn giữ nguyên tắc hay hoảng loạn thay đổi lập trường. Ứng viên senior giữ vững trục chính (đo bằng escape rate, giữ con người ở điểm phán đoán) nhưng linh hoạt điều chỉnh chiến thuật theo ràng buộc mới. Bài này sẽ liên tục minh hoạ cách nêu giả định rõ ràng, chọn một chỉ số làm điểm neo, rồi lập luận đánh đổi một cách bình tĩnh và có cấu trúc, thay vì đọc thuộc một danh sách công cụ thời thượng.
2. Câu hỏi 1 — AI hợp với tầng nào của kim tự tháp kiểm thử?
Đây là câu mở màn kinh điển. Câu trả lời mẫu bắt đầu bằng nguyên tắc: AI hữu ích nhất ở nơi công việc mang tính cơ học lặp lại và grounding được vào ứng dụng thật, còn con người giữ vai trò ở nơi cần phán đoán nghiệp vụ. Ở tầng unit, AI sinh nhanh nhiều case biên và gợi ý bảng dữ liệu, nhưng chi phí trên mỗi test rất thấp nên đừng phung phí token. Ở tầng integration/API, AI giỏi dựng hợp đồng và sinh biến thể payload. Ở tầng E2E, nơi test giòn nhất và tốn công bảo trì nhất, AI tạo giá trị lớn nhất qua sinh nháp và self-heal locator.
- Unit: AI gợi ý case biên & bảng dữ liệu — rẻ, nhưng oracle vẫn do người chốt.
- Integration/API: AI dựng contract, sinh biến thể payload, kiểm schema.
- E2E: AI mạnh nhất — nháp luồng, verify locator, self-heal khi UI đổi.
- Exploratory: AI lái browser để dò bug, sau đó ĐÓNG BĂNG thành spec tất định.
❓ Nếu chỉ được dùng AI ở một tầng, anh chọn tầng nào và vì sao?
Tôi chọn E2E. Đó là nơi test giòn nhất, bảo trì locator ngốn nhiều giờ nhất, và độ phủ luôn tụt sau tốc độ tính năng. Self-heal locator và sinh nháp luồng ở đây cắt được chi phí bảo trì lớn nhất, giải phóng người cho oracle và phân tích rủi ro (回帰 — regression). Unit đã rẻ và ổn định nên lợi ích biên của AI thấp hơn. Nhưng tôi nói rõ giả định: đây là tối ưu theo chi phí-lợi ích, không phải luật cứng.
3. Câu hỏi 2 — cái gì tự động hoá bằng AI, cái gì GIỮ con người?
Ranh giới đúng không phải 'AI làm mọi thứ' hay 'AI chỉ làm việc vặt', mà là chia theo bản chất công việc. Việc cơ học, lặp lại, verify được — như dựng khung test, sinh biến thể dữ liệu, sửa locator lỗi thời, phân loại log lỗi — hợp với AI. Việc cần phán đoán giá trị — thiết kế oracle, quyết định rủi ro nào chấp nhận được, đánh giá một 'lỗi' có thật là lỗi hay đúng yêu cầu, và quyết định merge — phải giữ ở con người. Nguyên tắc gọn: quyền cơ học của AI có thể rộng, nhưng quyền phán đoán và quyền merge thì hẹp và thuộc về người.
# ai-boundary.yml — chính sách ranh giới AI/người (đọc bởi CI & review bot)
ai_allowed: # AI được phép (cơ học, verify được)
- scaffold_test_drafts # sinh nháp *.spec.ts từ plan đã duyệt
- generate_data_variants # sinh biến thể payload / bảng data-driven
- heal_stale_locators # sửa locator lỗi thời -> đề xuất diff
- triage_error_logs # phân loại console/network/trace theo cụm
human_required: # con người bắt buộc chốt
- design_oracle # định nghĩa bất biến nghiệp vụ
- accept_risk # quyết rủi ro nào chấp nhận được
- classify_bug_vs_spec # 'lỗi' thật hay đúng yêu cầu?
- approve_merge # merge vào nhánh chính (CODEOWNERS)
policy:
ai_can_open_pr: true
ai_can_merge: false # tuyệt đối không
loosen_oracle_by_ai: forbidden❓ Vì sao KHÔNG bao giờ để AI tự quyết một test đỏ là 'flaky' rồi tắt nó?
Vì đó là quyền phán đoán trá hình thành quyền cơ học. Một test đỏ có thể là flaky thật, nhưng cũng có thể là bug thật vừa lọt. Nếu AI được tự tắt, nó có động cơ 'làm xanh pipeline' và sẽ che lỗi. Quy tắc: AI chỉ được ĐÁNH DẤU nghi ngờ flaky kèm bằng chứng (trace, số lần fail/pass), còn quyết định quarantine hay tắt là của người. Đây đúng là cái bẫy false-heal mà người phỏng vấn muốn nghe bạn nhận ra.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!