Mở đầu — vì sao bài này quan trọng
Trong sự nghiệp làm QA Lead hay Test Manager, có một sự thật khó chịu mà không sách vở nào nói thẳng: chất lượng đội ngũ của bạn quyết định 80% chất lượng chiến lược kiểm thử. Bạn có thể vẽ ra một test strategy đẹp long lanh, mua đủ công cụ đắt tiền, nhưng nếu tuyển sai người, mọi thứ sẽ sụp đổ trong âm thầm — bug lọt ra production, automation framework mục nát vì không ai bảo trì nổi, hoặc tệ hơn, cả team burn-out rồi lần lượt nghỉ việc.
Tuyển dụng QA là một trong những kỹ năng khó nhất của người làm quản lý chất lượng, và cũng là kỹ năng ít được đào tạo bài bản nhất. Nhiều QA Lead giỏi kỹ thuật nhưng khi ngồi ghế phỏng vấn lại lúng túng: không biết nên hỏi gì, không phân biệt được ứng viên "biết dùng Selenium" với ứng viên "hiểu vì sao mình tự động hóa test này", và thường tuyển theo cảm tính "thấy hợp thì nhận".
Bài này trang bị cho bạn một hiring framework — một khung tuyển dụng có cấu trúc: từ việc xác định đúng vai trò cần tuyển, xây dựng chân dung ứng viên (candidate profile), thiết kế quy trình phỏng vấn nhiều tầng, cho đến cách ra quyết định dựa trên bằng chứng thay vì cảm giác. Đây không phải lý thuyết HR chung chung, mà là khung áp dụng riêng cho đặc thù nghề QA tại thị trường Việt Nam và Đông Nam Á.
Khái niệm cốt lõi
Ba vai trò QA chuẩn — và đừng nhầm lẫn giữa chúng
Sai lầm phổ biến nhất khi build team là nghĩ "QA là QA", tuyển ai vào cũng làm được mọi việc. Thực tế, một QA team trưởng thành cần ba loại người rất khác nhau về tư duy và kỹ năng:
Manual QA (Kiểm thử thủ công / Domain-focused QA). Đây là người mạnh về domain expertise — hiểu sâu nghiệp vụ sản phẩm — và exploratory testing — khả năng "đánh hơi" bug ở những nơi không ai ngờ tới. Một Manual QA giỏi trong dự án ngân hàng phải hiểu luồng tất toán tài khoản, lãi suất, hạn mức tín dụng còn rõ hơn cả một số dev. Giá trị của họ không nằm ở việc "click theo test case", mà ở tư duy phản biện: "Nếu khách hàng làm điều điên rồ này thì sao?". Đừng bao giờ coi thường vai trò này — automation không thay thế được trực giác nghiệp vụ.
Automation QA / SDET (Software Development Engineer in Test). Đây là vai trò code-heavy — nặng về lập trình. SDET không chỉ viết test script, họ thiết kế và bảo trì cả kiến trúc framework tự động hóa, xây pipeline, viết test cho API, tích hợp vào CI/CD. Một SDET thực thụ phải code được ở trình độ gần với một mid-level developer. Đây là lý do SDET thường có mức lương cao nhất trong QA team — và cũng khó tuyển nhất tại Việt Nam vì nguồn cung khan hiếm.
Performance Engineer (Kỹ sư hiệu năng). Người chuyên sâu về JMeter, k6, Gatling, LoadRunner — thiết kế và chạy các bài test tải, đo throughput, latency, tìm bottleneck. Vai trò này rất chuyên biệt: họ phải hiểu cả hệ thống (database, network, JVM tuning, caching) chứ không chỉ biết bấm nút "run load test". Ở nhiều công ty vừa và nhỏ, đây là vai trò part-time hoặc thuê ngoài; nhưng ở fintech, e-commerce lớn thì đây là vị trí full-time không thể thiếu.
Ngoài ba vai trò trụ cột này, khi team lớn hơn bạn sẽ cần thêm QA Lead/Test Manager (điều phối chiến lược, con người) và có thể Security/Accessibility specialist. Nhưng ba vai trò trên là bộ khung nền tảng.
Candidate Profile — chân dung ứng viên trước khi mở JD
Trước khi viết Job Description, bạn phải trả lời: vai trò này tồn tại để giải quyết vấn đề gì? Đây gọi là role charter. Ví dụ: "Chúng ta có 3.000 test case chạy tay mỗi lần release, mất 5 ngày — cần một SDET tự động hóa 60% trong 6 tháng." Từ charter đó, bạn suy ra kỹ năng bắt buộc (must-have) và kỹ năng nên có (nice-to-have).
Nguyên tắc vàng: phân biệt rõ must-have và nice-to-have. JD của nhiều công ty Việt Nam liệt kê 15 công nghệ như một danh sách mua sắm, khiến ứng viên giỏi tự loại mình. Một SDET không cần biết cả Selenium lẫn Cypress lẫn Playwright lẫn Appium — họ cần tư duy tự động hóa vững và khả năng học công cụ mới nhanh.
Bốn trụ cột năng lực cần đánh giá
Với bất kỳ vai trò QA nào, hãy đánh giá theo bốn trục:
- Technical skills — kỹ thuật (coding, tool, kiến thức testing).
- Testing mindset — tư duy kiểm thử (khả năng đặt câu hỏi "what if", tìm edge case, tư duy phản biện).
- Communication — giao tiếp (viết bug report rõ ràng, thuyết phục dev fix, làm việc với BA/PO).
- Culture fit & growth — phù hợp văn hóa và tiềm năng phát triển.
Tình huống thực tế
Tình huống 1 — Tiki tuyển nhầm SDET vì chỉ hỏi lý thuyết
Một team QA tại một công ty e-commerce lớn ở TP.HCM (bối cảnh tương tự Tiki giai đoạn scale-up) cần tuyển SDET để cứu bộ automation đang xuống cấp. Vòng phỏng vấn của họ toàn câu hỏi lý thuyết: "Selenium WebDriver là gì?", "Page Object Model là gì?". Ứng viên A trả lời trơn tru mọi định nghĩa, được nhận với mức 28 triệu/tháng.
Ba tháng sau, thảm họa lộ ra: ứng viên A thuộc lòng lý thuyết nhưng khi phải viết một class xử lý wait động cho phần tử load bằng AJAX, anh ta bế tắc hoàn toàn. Framework anh viết đầy Thread.sleep(5000) cứng, khiến bộ test chạy 4 tiếng và flaky liên tục. Team phải thuê lại người khác, tốn thêm 3 tháng và mất niềm tin của dev vào automation.
Bài học: Với vai trò code-heavy như SDET, bắt buộc phải có bài coding thực tế — cho ứng viên viết code ngay tại chỗ hoặc làm take-home nhỏ. Hỏi định nghĩa không đo được năng lực thực thi. "Kể tên tool" không bằng "sửa đoạn code flaky này giúp tôi".
Tình huống 2 — Fintech VNPay-style và giá trị của domain expertise
Một startup fintech ở Hà Nội tuyển Manual QA cho sản phẩm ví điện tử. Có hai ứng viên: ứng viên B từng làm QA 4 năm cho một app game, kỹ năng test tổng quát rất tốt; ứng viên C chỉ có 2 năm QA nhưng từng làm ở một ngân hàng, hiểu rõ luồng thanh toán, đối soát, hoàn tiền.
Hiring manager ban đầu nghiêng về B vì kinh nghiệm nhiều hơn. Nhưng trong vòng phỏng vấn tình huống, họ đưa ra một bài: "Hãy liệt kê các trường hợp test cho tính năng chuyển tiền giữa hai ví." Ứng viên B nghĩ ra khoảng 10 case cơ bản. Ứng viên C nghĩ ra hơn 30, bao gồm: chuyển tiền khi số dư âm do phí, race condition khi hai giao dịch đồng thời, hoàn tiền sau khi tài khoản đích bị khóa, xử lý khi mất kết nối giữa chừng gây "tiền treo".
Họ chọn C. Sau 6 tháng, C phát hiện một lỗi đối soát nghiêm trọng có thể gây thất thoát tiền — thứ mà không automation nào bắt được vì nó nằm ở tầng nghiệp vụ.
Bài học: Trong domain phức tạp và rủi ro cao như fintech/banking, domain expertise và exploratory mindset có giá trị vượt trội so với số năm kinh nghiệm chung chung. Bài test tình huống ("liệt kê test case cho tính năng X") là công cụ đánh giá testing mindset hiệu quả nhất.
Tình huống 3 — Grab và bài học về communication bị bỏ quên
Một team tại một công ty công nghệ vùng (bối cảnh kiểu Grab/Gojek) tuyển một QA cực giỏi kỹ thuật — coding xuất sắc, tự động hóa nhanh. Nhưng họ bỏ qua hoàn toàn việc đánh giá kỹ năng giao tiếp. Kết quả: người này viết bug report kiểu "app lỗi, không chạy được", cãi nhau tay đôi với dev trong ticket, và khiến quan hệ QA–Dev căng thẳng đến mức các dev bắt đầu phớt lờ bug do anh ta báo.
Cuối cùng năng lực kỹ thuật của anh trở nên vô dụng vì không ai tin và phối hợp được. Team phải điều chuyển anh sang mảng chỉ làm việc với máy, không tiếp xúc người.
Bài học: QA là nghề giao tiếp nhiều hơn người ta tưởng. Một bug chỉ có giá trị khi được truyền đạt để người khác hành động. Luôn có ít nhất một phần phỏng vấn đánh giá cách ứng viên viết bug report và cách họ phản ứng khi bị dev phản bác.
Hướng dẫn từng bước
Đây là quy trình tuyển dụng QA chuẩn, áp dụng được cho cả ba vai trò (điều chỉnh độ nặng kỹ thuật theo từng role):
Bước 1 — Viết Role Charter (nửa trang). Trả lời ba câu: Vai trò này giải quyết vấn đề gì? Thành công sau 6 tháng trông thế nào? Ai là stakeholder chính? Đừng viết JD trước khi có charter.
Bước 2 — Xây Candidate Profile & tách must-have / nice-to-have. Với SDET, must-have thường là: code được một ngôn ngữ (Java/Python/JS), hiểu tư duy automation, biết Git/CI cơ bản. Nice-to-have: một tool cụ thể. Với Manual QA fintech, must-have là domain + exploratory mindset. Đừng nhét quá 5 must-have.
Bước 3 — Viết JD trung thực và cụ thể. Nêu rõ vấn đề thực tế của team, tech stack thật, cơ hội phát triển. Tránh JD "sao chép mạng" liệt kê 15 công nghệ. JD trung thực lọc đúng người ngay từ đầu và giảm tỷ lệ nghỉ sớm.
Bước 4 — Sàng lọc CV theo bằng chứng, không theo từ khóa. Đừng loại người vì thiếu đúng tên tool. Tìm dấu hiệu tư duy: họ mô tả đã giải quyết vấn đề gì, hay chỉ liệt kê đã dùng gì? Một CV viết "giảm thời gian regression từ 3 ngày xuống 4 giờ" đáng giá hơn CV liệt kê 20 công cụ.
Bước 5 — Thiết kế quy trình phỏng vấn nhiều tầng. Một cấu trúc tốt (điều chỉnh theo cấp bậc):
- Vòng 1 — Screening (30 phút): xác minh kinh nghiệm, động lực, mức lương kỳ vọng.
- Vòng 2 — Technical/Practical (60–90 phút): với SDET là coding thực tế (sửa code flaky, viết test cho một API); với Manual QA là bài tình huống (liệt kê test case cho một tính năng, test một sản phẩm thật ngay tại chỗ); với Performance Engineer là mổ xẻ một kịch bản load test và cách phân tích bottleneck.
- Vòng 3 — Behavioral & Communication: dùng câu hỏi STAR ("Kể lần bạn bất đồng với dev về một bug"), yêu cầu viết một bug report mẫu.
- Vòng 4 — Culture & Growth (với Lead/Manager): đánh giá phù hợp giá trị và tiềm năng.
Bước 7 — Debrief và ra quyết định tập thể. Họp nhanh, mỗi người trình bày điểm và bằng chứng. Nguyên tắc: nếu có "red flag" rõ ràng ở must-have thì loại, đừng vì thiếu người mà nhắm mắt tuyển.
Bước 8 — Chốt offer và chuẩn bị onboarding. (Phần onboarding chi tiết sẽ ở bài tiếp theo — ở đây chỉ cần đảm bảo có kế hoạch đón người.)
Lỗi thường gặp & mẹo
Lỗi 1 — Tuyển "generalist" cho mọi vị trí. Kỳ vọng một người vừa manual giỏi, vừa code SDET, vừa làm performance. "Người toàn năng" như vậy cực hiếm và thường không sâu ở mảng nào. Mẹo: xác định rõ vai trò trọng tâm trước, rồi mới tính đến kỹ năng phụ.
Lỗi 2 — Chỉ hỏi lý thuyết, không kiểm thực hành. Như tình huống Tiki: định nghĩa thuộc lòng không đo được năng lực. Mẹo: mọi vai trò kỹ thuật phải có bài thực hành. Kể cả Manual QA cũng nên "test thử" một app thật ngay trong buổi phỏng vấn.
Lỗi 3 — Bỏ qua communication. Mẹo: luôn yêu cầu ứng viên viết một bug report mẫu và quan sát cách họ phản ứng khi bạn "đóng vai dev phản bác".
Lỗi 4 — Take-home test quá dài. Bắt ứng viên làm bài 8 tiếng khiến người giỏi (đang có việc) bỏ cuộc. Mẹo: giữ take-home dưới 2 tiếng, hoặc thay bằng pair-testing/live coding.
Lỗi 5 — Tuyển vội vì áp lực nhân sự. "Thiếu người quá, tạm nhận đại." Một QA sai còn tệ hơn không có QA, vì họ tạo cảm giác an toàn giả. Mẹo: giữ vững bar tuyển; nếu thiếu người, cân nhắc thuê contractor ngắn hạn thay vì tuyển sai vĩnh viễn.
Lỗi 6 — Chỉ dựa vào một người phỏng vấn. Bias cá nhân dễ dẫn đến quyết định sai. Mẹo: dùng panel + scorecard + debrief tập thể.
Mẹo bổ sung cho thị trường Việt Nam: SDET giỏi khan hiếm, hãy cân nhắc chiến lược "hire for potential" — tuyển Manual QA có nền tảng lập trình và tư duy tốt, rồi đầu tư đào tạo thành SDET. Nhiều công ty như FPT, VNG đã build đội automation theo cách này thành công.
Bài tập thực hành
- Viết Role Charter: Chọn một trong ba vai trò (Manual QA / SDET / Performance Engineer) cho một sản phẩm giả định của bạn. Viết charter nửa trang: vai trò giải quyết vấn đề gì, thành công sau 6 tháng ra sao.
- Tách must-have / nice-to-have: Từ charter trên, liệt kê tối đa 5 kỹ năng must-have và 5 nice-to-have. Tự phản biện: có kỹ năng nào bạn đang liệt kê "must" nhưng thực ra có thể đào tạo được không?
- Thiết kế một câu hỏi phỏng vấn cho từng trụ cột: Viết 4 câu hỏi — mỗi câu đo một trong bốn trục (technical, mindset, communication, culture) — cho vai trò bạn đã chọn.
- Thiết kế bài thực hành: Với SDET, hãy soạn một đoạn code flaky (dùng
Thread.sleep) để ứng viên sửa. Với Manual QA, chọn một tính năng thật (ví dụ: chức năng đặt lại mật khẩu) và tự liệt kê 20+ test case — đây chính là "đáp án mẫu" để chấm ứng viên.
- Tạo scorecard: Lập một bảng scorecard 4 cột (theo bốn trụ cột), thang điểm 1–5, có cột ghi chú bằng chứng. Đây là công cụ bạn sẽ dùng thật khi phỏng vấn.
Tóm tắt
Xây dựng QA team bắt đầu từ việc phân biệt đúng ba vai trò cốt lõi: Manual QA (mạnh domain và exploratory), Automation QA/SDET (nặng code, xây framework và CI/CD), và Performance Engineer (chuyên sâu JMeter/k6, phân tích bottleneck). Mỗi vai trò cần chân dung ứng viên và cách đánh giá khác nhau.
Một hiring framework tốt luôn: xuất phát từ role charter, tách rõ must-have / nice-to-have, sàng lọc theo bằng chứng thay vì từ khóa, và đánh giá theo bốn trụ cột (technical, testing mindset, communication, culture). Ghi nhớ ba bài học từ thực tế: với vai trò code-heavy phải có coding thực tế; trong domain rủi ro cao domain expertise thắng số năm kinh nghiệm; và đừng bao giờ bỏ qua communication vì một bug chỉ có giá trị khi được truyền đạt để người khác hành động. Cuối cùng, giữ vững bar tuyển dụng — một QA sai còn nguy hiểm hơn không có QA, vì nó tạo cảm giác an toàn giả.