40 câu hỏi phỏng vấn Manual Tester từ Fresher đến Senior

Vì sao mình chia thành 4 level?

Khi đi tuyển, mình thấy nhiều bạn tự gán mình là "Junior 1 năm kinh nghiệm" hoặc "Senior 5 năm" rất chung chung. Thực tế các công ty đánh giá theo năng lực chứ không phải số năm. Mình đã gặp bạn 6 tháng kinh nghiệm trả lời như Middle, và cũng gặp bạn 4 năm kinh nghiệm chỉ ở mức Junior.

Cách mình phân định:

Phần 1 — Fresher: Đừng coi thường lý thuyết cơ bản

10 câu đầu tiên kiểm tra nền tảng. Nghe đơn giản nhưng đây là chỗ rất nhiều bạn trượt vì học vẹt.

Ví dụ câu kinh điển: "Severity và Priority khác nhau ra sao? Cho ví dụ Severity cao – Priority thấp và ngược lại."

Đa số bạn trả lời được phần định nghĩa. Nhưng đến phần ví dụ thì bí. Có bạn còn nói "Severity cao thì Priority cũng cao" — chứng tỏ chỉ thuộc lý thuyết mà không hiểu.

Câu trả lời tốt phải có ví dụ thực tế:

• Severity cao – Priority thấp: Crash khi user nhập 10.000 ký tự vào ô tên. Nghiêm trọng về kỹ thuật nhưng hiếm khi xảy ra, không cần fix gấp.
• Severity thấp – Priority cao: Sai logo công ty trên trang chủ. Về kỹ thuật chỉ là lỗi hiển thị, nhưng ảnh hưởng thương hiệu nên phải fix ngay.

Mẹo cho Fresher: Khi học lý thuyết, luôn tự đặt câu hỏi "ví dụ thực tế là gì?". Nếu không nghĩ ra được ví dụ tức là bạn chưa thật sự hiểu.

Phần 2 — Junior: Bắt đầu phải có "đầu tư duy"

Đến level Junior, người phỏng vấn không hỏi định nghĩa nữa. Họ ném case cụ thể cho bạn.

Câu mình thấy lọc người mạnh nhất ở vòng này: "Liệt kê test case cho chức năng Đăng nhập."

• Ứng viên yếu: liệt kê được 3–5 case (đúng/sai password, để trống, sai email format).
• Ứng viên Junior khá: liệt kê 10–15 case, có nghĩ đến edge case.
• Ứng viên xuất sắc: liệt kê 20+ case, phân nhóm rõ ràng (functional, security, UX, performance), nghĩ đến SQL injection, XSS, brute force, session timeout, remember me, login concurrent từ 2 device...

Sự khác biệt không phải ở lượng case mà ở cách tư duy. Junior tốt sẽ tự đặt câu hỏi:

• User dùng tính năng này trong context nào?
• Hacker có thể tấn công ở đâu?
• Edge case nào dev hay quên?
• Tính năng này tương tác với cái gì khác (forgot password, OAuth, session)?

Một câu nữa rất hay: "Tình huống: deadline còn 1 ngày, còn 200 test case chưa chạy. Bạn xử lý sao?"

Câu này không có đáp án "đúng". Người phỏng vấn xem cách bạn ra quyết định dưới áp lực:

• Có biết áp dụng risk-based testing không?
• Có dám báo cáo minh bạch với PM không?
• Hay là cố gắng chạy hết để rồi miss bug nặng?

Phần 3 — Middle: Level chuyển tiếp khó nhằn nhất

Cá nhân mình thấy Middle là level khó định nghĩa nhất. Bạn không còn là Junior để được dắt tay, nhưng cũng chưa đủ để dẫn dắt người khác. Đây là level mà nhiều bạn "stuck" lâu nhất trong sự nghiệp.

Câu hỏi mình hay dùng để đánh giá Middle: "Bug bạn report bị dev đánh Not a bug / Rejected. Bạn làm gì?"

Phản ứng của ứng viên tiết lộ rất nhiều về văn hóa làm việc:

• Trả lời tệ: "Em sẽ đi báo với leader" → thiếu khả năng tự giải quyết.
• Trả lời trung bình: "Em sẽ reopen bug" → cứng nhắc, không suy nghĩ.
• Trả lời tốt: "Em sẽ đọc lại requirement, hỏi BA để confirm expected behavior. Nếu đúng là bug thì reopen kèm bằng chứng và reference spec. Nếu sai thì em học từ đó. Đôi khi spec chưa rõ thì em đề xuất clarify cả team."

Sự khác biệt nằm ở mindset: Middle không cãi để thắng, mà tìm root cause của bất đồng.

Một câu khác mình rất thích: "Performance, Load, Stress, Spike Testing khác nhau ra sao? Tool và metric chính bạn quan tâm?"

Middle phải biết được rằng:

• Metric quan trọng không phải là average response time, mà là p95, p99.
• Average đánh lừa người đọc — 99 user nhanh nhưng 1 user chờ 30 giây vẫn ra trung bình "đẹp".
• Khi báo cáo phải kèm error rate, throughput, không chỉ response time.

Cái này là kiến thức mà Junior chưa cần biết, nhưng Middle thì phải có.

Phần 4 — Senior: Không còn là chuyện kỹ thuật

Đến Senior, kỹ thuật chỉ là điều kiện cần, không phải điều kiện đủ. Người phỏng vấn quan tâm hơn đến tư duy hệ thống, khả năng lead team, và ra quyết định chiến lược.

Câu mình hay hỏi: "Bạn được giao build QA process cho 1 startup chưa có quy trình test. Bạn bắt đầu từ đâu?"

Câu trả lời tốt phải thể hiện được:

1. Không bê nguyên enterprise process vào startup — đây là sai lầm kinh điển.
2. Audit trước, action sau — hiểu hiện trạng team, tool, deadline.
3. Balance giữa "đúng quy trình" và "đủ dùng" — startup cần tốc độ, không cần ISO certification.
4. Có roadmap rõ ràng — tuần 1 làm gì, tháng 1 làm gì, quý 1 làm gì.

Câu nữa cực kỳ lọc người: "Làm sao bạn đo lường hiệu quả của team QA? KPI/metric nào dùng và metric nào tránh?"

Senior thật sẽ biết:

• Metric tốt: Defect Leakage, Defect Removal Efficiency, Escaped Defects, MTTR.
• Metric độc hại: số bug raised/tester (tester sẽ chia nhỏ bug ra để ăn KPI), số test case viết được (số lượng ≠ chất lượng).

Người chưa đủ Senior thường liệt kê được metric, nhưng không biết metric nào sinh ra hành vi sai. Senior phải hiểu: metric sai → behavior sai → product sai.

5 sai lầm phổ biến mình thấy ở ứng viên QA

Sau khi phỏng vấn vài chục bạn, mình rút ra 5 sai lầm gần như ai cũng mắc ít nhất 1 lần:

1. Học vẹt định nghĩa mà không có ví dụ. Hỏi gì cũng trả lời theo sách. Khi yêu cầu cho ví dụ thực tế thì bí.

2. Trả lời "đúng sách" cho câu tình huống. Câu tình huống không có đáp án đúng. Người phỏng vấn xem cách bạn suy nghĩ, không phải đáp án.

3. Nói xấu công ty cũ / sếp cũ / dev cũ. Dấu hiệu cực kỳ xấu. Nhà tuyển dụng sẽ nghĩ "rồi mai mốt bạn cũng nói xấu mình như vậy".

4. Không hỏi lại khi câu hỏi mơ hồ. Ví dụ "Test cái thang máy". Ứng viên giỏi sẽ hỏi: "Thang máy mấy tầng? Ở chung cư hay cao ốc văn phòng? Có load weight sensor không?". Ứng viên kém thì lao vào liệt kê ngay.

5. Cố tỏ ra biết tất cả. Nói "em không rõ phần này nhưng em sẽ tìm hiểu" mạnh hơn nhiều so với việc bịa câu trả lời. Senior interviewer phát hiện ngay khi bạn bịa.

Dùng bộ 40 câu này như thế nào?

Nếu bạn là ứng viên đang ôn phỏng vấn:

• Đừng đọc đáp án trước. Tự trả lời bằng giấy bút, sau đó so với gợi ý.
• Câu nào trả lời được dưới 30 giây mà chưa đủ ý → đó là câu cần ôn lại.
• Ghi âm khi tự trả lời. Nghe lại sẽ phát hiện rất nhiều điểm yếu (nói lan man, "ờm" nhiều, không kết luận).
• Luyện với người khác (mock interview) sẽ hiệu quả gấp 10 lần đọc một mình.

Nếu bạn là HR/Lead đi tuyển QA:

• Đừng hỏi cả 40 câu — buổi phỏng vấn không đủ thời gian. Chọn 5–8 câu theo level cần tuyển.
• Câu tình huống (13, 19, 23, 26, 30) đánh giá thái độ tốt hơn câu lý thuyết.
• Nếu ứng viên trả lời quá trơn tru, đào sâu bằng follow-up: "Cho 1 ví dụ thực tế bạn đã làm việc đó." Câu hỏi này lọc ứng viên thật vs ứng viên đọc nhiều blog.
• Đừng chỉ chấm câu trả lời. Chấm cả cách họ đặt câu hỏi lại, cách họ xử lý khi không biết.

Lời nhắn cuối

Phỏng vấn QA bây giờ cạnh tranh hơn 3 năm trước rất nhiều. Số lượng người học QA tăng nhanh, nhưng số người làm QA thật sự tốt thì không tăng nhiều. Nếu bạn đầu tư đúng vào tư duy và kỹ năng (chứ không chỉ chứng chỉ), bạn sẽ luôn có việc.

40 câu này chỉ là điểm khởi đầu. Cái khó nhất của nghề QA không phải là biết test cái gì, mà là biết cái gì KHÔNG cần test và biết khi nào dừng. Cái này phải đi làm 2–3 năm mới ngấm.

Chúc các bạn phỏng vấn thuận lợi. Nếu thấy bài này hữu ích, share cho bạn bè đang đi tìm việc QA.

File PDF bộ 40 câu hỏi đầy đủ kèm gợi ý đáp án

[40_cau_phong_van_manual_tester]

Bài viết bởi Anh Tester. Đọc thêm các bài chia sẻ về testing, automation, career path tại https://anhtester.com/blogs.