30 câu hỏi phỏng vấn Senior Test Automation kèm Gợi ý trả lời

Có một câu hỏi mình từng nghe trong buổi phỏng vấn một bạn ứng tuyển Senior Automation: "Theo em, vì sao team mình nên giữ Selenium thay vì chuyển hết sang Playwright?"

Bạn đó trả lời trơn tru về cú pháp, về auto-wait, về tốc độ. Toàn kiến thức đúng. Nhưng không một lần nhắc đến chi phí migrate, năng lực hiện tại của team, hay rủi ro khi viết lại cả bộ test đang chạy ổn. Hỏi một câu chiến lược, nhận về một câu trả lời kỹ thuật.

Đó là khác biệt giữa người biết công cụ và người được thuê làm senior.

Ở cấp senior, chẳng ai trả lương cao để bạn đọc thuộc tài liệu — định nghĩa thì tra một phút là ra. Người ta trả tiền cho phán đoán của bạn: khi nào nên dùng gì, đánh đổi cái gì, và giải thích được lựa chọn đó cho cả team lẫn sếp nghe. Bộ 30 câu này được viết đúng theo tinh thần ấy.



Vì sao "đáp án đúng" không còn là thứ quan trọng nhất

Đây là điều mình muốn bạn ghi nhớ trước khi đọc tiếp: ở vị trí senior, cách bạn lập luận quan trọng hơn kết luận bạn đưa ra.

Lấy một ví dụ. Câu hỏi: "Khi nào nên tự động hóa một test case và khi nào nên giữ kiểm thử thủ công?"

Một bạn junior sẽ trả lời: "Tự động hóa những case lặp đi lặp lại." Đúng, nhưng nông.

Một bạn senior sẽ trả lời khác: "Tùy. Mình cân nhắc tần suất chạy, độ ổn định của feature, chi phí maintain về sau, và mức độ rủi ro nếu nó hỏng. Một case chạy mỗi ngày trên một module ổn định thì nên tự động. Nhưng một feature đang thay đổi liên tục mỗi sprint thì tự động hóa sớm chỉ tổ tốn công sửa script — giai đoạn đó mình ưu tiên exploratory."

Thấy khác biệt chưa? Người thứ hai không chỉ trả lời câu hỏi — họ cho thấy họ suy nghĩ bằng trade-off. Đó chính xác là thứ interviewer cấp senior đang lắng nghe.


30 câu, 5 nhóm năng lực

Bộ câu hỏi này không sắp xếp theo công cụ, mà theo năng lực mà một Senior Test Automation thật sự cần:

Chiến lược & tư duy automation (câu 1–4) — Khi nào tự động hóa, test automation pyramid, đo ROI, và xử lý flaky test. Đây là nhóm phân biệt người "viết được script" với người "định hình được chiến lược test".

Thiết kế framework & kiến trúc (câu 5–9) — Xây framework từ đầu, Page Object Model vs Screenplay, quản lý test data, chạy song song, và synchronization. Nhóm này lộ ra ngay bạn đã từng thiết kế hay chỉ dùng framework người khác viết.

Kỹ thuật & công cụ (câu 10–13) — So sánh Selenium/Playwright/Cypress, API automation, kiểm thử hệ bất đồng bộ, performance testing.

CI/CD & DevOps (câu 14–16) — Tích hợp test vào pipeline, tối ưu thời gian chạy, quản lý môi trường với Docker.

Lãnh đạo & vai trò Senior (câu 17–20) — Mentor junior, xử lý khi developer không quan tâm chất lượng, kể về một quyết định sai, và vai trò chiến lược của QA trong cả vòng đời sản phẩm.

Và vì thị trường 2026 đòi hỏi nhiều hơn, mình thêm 10 câu chuyên sâu (21–30): mobile automation, visual regression, mock/stub/fake/spy, contract testing trong microservices, chiến lược locator, metrics đo "sức khỏe" bộ test, BDD/Cucumber, quản lý test code như production code, risk-based testing, và quan điểm về AI/self-healing test cùng shift-right.


Ba câu mình muốn bạn để ý

Thay vì kể hết 30 câu, mình lôi ra ba câu mà theo kinh nghiệm của mình, lọc người giỏi rất nhanh.

Câu về flaky test. Ai cũng nói được "flaky là test lúc pass lúc fail". Nhưng người senior sẽ chỉ ra nguyên nhân thật: timing/synchronization, test data không độc lập, phụ thuộc thứ tự chạy, môi trường. Và quan trọng hơn — họ có chiến lược: quarantine test flaky, retry có kiểm soát, fix tận gốc thay vì giấu lỗi, và theo dõi tỷ lệ flaky như một metric. Người trả lời "thì cứ retry vài lần là được" đã tự loại mình. Retry để giấu lỗi là một trong những thói quen nguy hiểm nhất của automation.

Câu về synchronization. Nghe đơn giản, nhưng đây là câu mình thích nhất để hỏi. Nếu một ứng viên còn dùng Sleep hay Delay "cho chắc" rồi tăng lên 10000 khi vẫn fail — bạn biết ngay họ chưa hiểu vấn đề. Người senior sẽ nói về explicit wait theo điều kiện cụ thể: chờ element clickable, chờ API hoàn tất, chờ một trạng thái rõ ràng. Sleep cố định vừa làm test chậm, vừa không đáng tin.

Câu về chiến lược locator. Đây là câu "kỹ thuật nhỏ nhưng lộ tư duy lớn". Người dùng XPath tuyệt đối dài ngoằng phụ thuộc cấu trúc DOM sẽ có bộ test gãy mỗi lần dev đổi giao diện. Người senior ưu tiên data-testid, chủ động phối hợp với dev để thêm test hook, và tập trung hóa locator để dễ bảo trì. Câu trả lời cho thấy họ hiểu rằng chi phí lớn nhất của automation không phải lúc viết, mà là lúc maintain.


Đừng học thuộc — hãy chuẩn bị ví dụ

Đây là lời khuyên thật lòng, không phải khẩu hiệu: với mỗi câu trong bộ 30 này, đừng học thuộc câu trả lời mẫu. Thay vào đó, chuẩn bị một ví dụ thực tế từ chính dự án của bạn.

Công thức đơn giản: bối cảnh → lựa chọn bạn đưa ra → lý do → kết quả.

Khi bạn nói "Ở dự án X, bộ E2E chạy 45 phút làm pipeline tắc nghẽn, mình đẩy phần lớn assertion xuống tầng API và contract test, giữ lại E2E cho 8 luồng quan trọng nhất, kết quả còn 12 phút" — câu đó đánh bại mọi định nghĩa sách vở. Interviewer biết bạn đã thật sự làm, không phải đọc nhiều blog.

Và nếu quan điểm của bạn khác với gợi ý trong tài liệu? Cứ trình bày. Miễn là bạn bảo vệ được. Một senior dám phản biện có lý còn giá trị hơn một người gật đầu theo đáp án mẫu.


Routine một tuần trước phỏng vấn

Nếu bạn còn một tuần, đây là cách mình gợi ý dùng bộ 30 câu:

  • Ngày 1–2: Đọc hết 30 câu, đánh dấu những câu bạn không tự tin. Đa số sẽ rơi vào nhóm framework design và CI/CD.
  • Ngày 3–4: Với mỗi câu yếu, viết ra một ví dụ thật từ dự án của bạn. Không có ví dụ? Đó là tín hiệu bạn cần ôn lại trải nghiệm hoặc thực hành thêm.
  • Ngày 5: Tự trả lời thành tiếng và ghi âm lại. Nghe lại sẽ phát hiện bạn nói lan man, "ờm" nhiều, hay không có kết luận.
  • Ngày 6: Mock interview với một đồng nghiệp. Hiệu quả gấp nhiều lần tự luyện một mình.
  • Ngày 7: Nghỉ. Đọc lướt lại phần "nên tránh". Đi ngủ sớm.

 

Hai phiên bản, hai mục đích

Mình làm bộ này thành hai bản tài liệu PDF riêng:

Một bản cho ứng viên — mỗi câu có phần "Nên nêu" (điểm bạn nên trình bày) và "Nên tránh" (lỗi thường gặp). Dùng để tự ôn.

Một bản cho người phỏng vấn (HR, Test Lead) — cùng 30 câu nhưng diễn đạt theo hướng chấm điểm: "câu trả lời tốt nên thể hiện điều gì" và "red flag" cần để ý. Nếu bạn là người đi tuyển, đừng hỏi cả 30 câu — chọn 6–8 câu theo đúng thứ bạn cần, và luôn đào sâu bằng follow-up: "Cho mình một ví dụ thực tế bạn đã làm việc đó." Câu này lọc ứng viên thật khỏi ứng viên đọc nhiều blog.


📹 Kênh Vlog của An: Đi Hoài Không Chán

Các bạn vào đăng ký kênh giúp mình cho nó lên 1000 với nhen, cảm ơn bạn rất nhiều. Mình sẽ chia sẻ tài liệu và khoá học miễn phí sắp tới sang email mà bạn đã đăng ký kênh Vlog này nhé ❤️

📥 TẢI VỀ FILE PDF:

Bản dành cho Ứng viên: 30 Câu hỏi phỏng vấn Senior Test Automation dành cho Ứng viên

Bản dành cho Người phỏng vấn: 30 Câu hỏi phỏng vấn Senior Test Automation dành cho Người phỏng vấn

 

Lời nhắn cuối

Thị trường automation ở Việt Nam đang trưởng thành nhanh. Số người biết viết script tăng vùn vụt, nhưng số người tư duy được như một senior thì vẫn hiếm. Mảng banking, insurance, ERP — nơi trả lương tốt và ổn định — luôn cần người hiểu trade-off, hiểu rủi ro, biết nói chuyện với cả dev lẫn business, chứ không chỉ biết technical code automation.

Bộ 30 câu này không biến bạn thành chuyên gia sau một đêm. Nhưng nó cho bạn đủ vũ khí để bước vào buổi phỏng vấn tiếp theo một cách tự tin — và quan trọng hơn, biết phản ứng khôn ngoan trước những câu hỏi bạn chưa từng gặp.

Nếu tài liệu giúp ích, hãy chia sẻ cho đồng nghiệp đang cần. Đó là cách tốt nhất để cộng đồng QA Việt Nam mạnh lên.


Xem thêm các câu hỏi phỏng vấn khác tại đây

 

Anh Tester — Cộng đồng Automation Testing Việt Nam

🌐 https://anhtester.com

  • Anh Tester

    Đường dẫu khó chân vẫn cần bước đi
    Đời dẫu khổ tâm vẫn cần nghĩ thấu