Câu hỏi phỏng vấn tester junior thường gặp từ nhà tuyển dụng Việt Nam

Chuẩn bị gì trước buổi phỏng vấn tester?

Mình nhớ lần đầu đi phỏng vấn vị trí manual tester. Chuẩn bị cả tuần lý thuyết, nhưng bước vào phòng, HR hỏi "Em mô tả quy trình test của em đi" - mình ngồi im 10 giây không biết bắt đầu từ đâu.

Vấn đề không phải mình không biết. Vấn đề là chưa bao giờ luyện nói thành lời.

Bài này tổng hợp câu hỏi thực tế mà nhà tuyển dụng Việt Nam hay hỏi khi phỏng vấn tester junior - dựa trên job description từ ITviec và TopDev, cùng chia sẻ từ cộng đồng Testing Việt Nam. Không phải lý thuyết sách vở, mà là câu hỏi bạn sẽ gặp thật.

Chuẩn bị kỹ câu trả lời giúp bạn tự tin hơn trong phòng phỏng vấn

Mỗi câu hỏi mình gợi ý cách trả lời ngắn gọn - không cần học thuộc lòng, chỉ cần hiểu ý và nói theo cách tự nhiên của bạn. Một điều quan trọng: nhà tuyển dụng junior không kỳ vọng bạn biết hết. Họ đánh giá bạn có tư duy không, có ham học không, có tỉ mỉ không.

Câu hỏi về kiến thức testing cơ bản

Đây là nhóm câu hỏi xuất hiện gần như luôn xuất hiện trong các buổi phỏng vấn tester junior. HR và tech lead muốn chắc bạn hiểu nền tảng trước khi nói chuyện sâu hơn.

"Testing là gì? QA và QC khác nhau thế nào?"

Câu này nghe cơ bản nhưng nhiều bạn lẫn lộn. Cách trả lời tốt:

• Testing: Kiểm tra phần mềm có hoạt động đúng như mong đợi không, tìm ra lỗi trước khi đến tay người dùng.
• QA (Quality Assurance): Đảm bảo quy trình làm việc đúng - ngăn lỗi phát sinh từ đầu.
• QC (Quality Control): Kiểm tra sản phẩm cuối - phát hiện lỗi đã có.

Nói đơn giản: QA là "làm đúng quy trình", QC là "kiểm tra sản phẩm". Phần lớn vị trí tester junior ở VN thực ra làm cả hai.

"Test case là gì? Bạn viết test case như thế nào?"

Test case là kịch bản mô tả: cần test cái gì, làm thế nào để test, kết quả mong đợi là gì. Giống như công thức nấu ăn - có nguyên liệu (precondition), có các bước (steps), có thành phẩm mong đợi (expected result).

Khi trả lời, bạn có thể nêu ví dụ ngay: "Em sẽ test tính năng đăng nhập với các trường hợp: đúng username/password, sai password, bỏ trống, nhập ký tự đặc biệt..."

Test case tốt phải rõ precondition, steps và expected result

"Vòng đời của một bug là gì?"

Đây là câu hỏi kỹ thuật phổ biến. Trả lời theo flow: New → Assigned → Open → Fixed → Re-test → Closed (hoặc Reopen nếu chưa fix xong).

Bạn không cần thuộc lòng từng trạng thái, nhưng phải hiểu logic: bug được tìm thấy → giao dev fix → tester kiểm tra lại → đóng hoặc mở lại.

"Smoke testing, sanity testing, regression testing khác nhau thế nào?"

Nhiều bạn hoảng khi gặp câu này. Thật ra không khó:

• Smoke testing: Test nhanh "sống hay chết" - app bật lên được không, tính năng cơ bản chạy không. Như bật điện thoại xem sáng màn hình không.
• Sanity testing (kiểm tra tỉnh táo): Sau fix bug, test nhanh đúng phần đó có ổn không.
• Regression testing (kiểm thử hồi quy): Test lại toàn bộ tính năng cũ để đảm bảo fix mới không làm hỏng cái cũ.

Mình hay nhớ bằng ví dụ: mua xe mới (smoke test xem xe nổ máy được không), thay lốp (sanity test lốp mới ok không), sau đó lái thử cả xe (regression test xe vẫn chạy bình thường).

Câu hỏi về quy trình làm việc thực tế

Sau phần kiến thức cơ bản, tech lead thường chuyển sang hỏi bạn làm việc như thế nào trong thực tế. Mục tiêu: xem bạn có tư duy tester thật hay chỉ học vẹt.

"Bạn nhận được tính năng mới, bạn sẽ làm gì đầu tiên?"

Đây là câu mình thích nhất vì nó lộ rõ tư duy. Câu trả lời tệ: "Em sẽ test ngay." Câu trả lời tốt hơn:

1. Đọc kỹ requirements/spec (nếu có)
2. Hỏi BA hoặc dev nếu chưa rõ
3. Lên danh sách test cases: happy path trước, rồi negative cases, edge cases
4. Thực hiện test theo từng case
5. Log bug nếu có
6. Report kết quả

Bạn không cần nói đủ 6 bước ngay, nhưng phải thể hiện bạn không test mù - có kế hoạch trước khi làm.

Quy trình rõ ràng giúp không bỏ sót test case quan trọng

"Khi dev nói 'không phải bug, là feature', bạn xử lý thế nào?"

Câu này kiểm tra kỹ năng mềm của bạn. Trả lời thẳng thắn nhưng không mang tính đối đầu:

• Quay lại requirements/spec để kiểm tra hành vi mong đợi
• Nếu không có tài liệu rõ ràng, escalate lên BA hoặc PM để làm rõ
• Không phán xét hay tranh luận trực tiếp với dev

Nhà tuyển dụng muốn thấy bạn xử lý bằng tài liệu và quy trình, không phải cảm tính.

"Bạn test thế nào khi không có tài liệu requirements?"

Tình huống này thực ra rất phổ biến ở startup VN. Câu trả lời thực tế:

• Dùng exploratory testing (kiểm thử khám phá): chủ động khám phá app để hiểu nó làm gì
• Hỏi người liên quan: dev, PM, hoặc dùng thử app version cũ (nếu có)
• Dựa vào common sense: app tương tự trên thị trường hoạt động thế nào
• Ghi chép lại những gì mình hiểu và confirm với team

Đừng ngại thừa nhận là khó - nhưng phải cho thấy bạn có cách xử lý.

Câu hỏi về viết bug report

Nếu phỏng vấn có bài test thực hành, khả năng cao bạn sẽ được yêu cầu viết bug report. Nhưng kể cả không có bài test, câu hỏi về bug report gần như chắc chắn xuất hiện.

"Bug report tốt cần có những gì?"

Bug report tốt phải đủ để dev tái hiện lại bug mà không cần hỏi thêm. Cấu trúc chuẩn:

Mình hay nhắc nhở: Một bug report thiếu "steps to reproduce" gần như vô dụng. Dev không thể fix bug nếu không reproduce được.

Bug report đủ thông tin giúp dev fix nhanh hơn, không mất thời gian hỏi lại

"Severity và Priority khác nhau thế nào?"

Câu hỏi này hay bẫy người mới. Nhiều bạn nghĩ hai cái giống nhau.

• Severity (mức độ nghiêm trọng kỹ thuật): Bug ảnh hưởng đến hệ thống nặng đến đâu. App crash = Critical. Lỗi chính tả = Trivial.
• Priority (mức độ ưu tiên fix): Bug cần fix sớm đến đâu, theo góc độ business.

Ví dụ thực tế: Lỗi chính tả tên CEO trên trang About = Severity thấp (Trivial) nhưng Priority cao (phải fix trước họp báo). Ngược lại, tính năng xuất báo cáo lỗi = Severity cao nhưng Priority thấp nếu ít người dùng.

"Bạn phân loại severity thế nào?"

• Critical: App không dùng được, data mất, hệ thống crash
• Major: Tính năng chính không hoạt động nhưng app vẫn chạy
• Minor: Tính năng phụ lỗi nhưng có cách đi vòng
• Trivial: Lỗi nhỏ về UI, chính tả, không ảnh hưởng chức năng

Mình tải sẵn Tải mẫu bug report template nếu bạn muốn luyện viết bug report trước phỏng vấn - đã có mẫu điền sẵn các trường chuẩn.

Câu hỏi về kinh nghiệm và dự án cá nhân

Nhiều bạn trái ngành sợ nhất phần này vì "em chưa có kinh nghiệm". Thật ra đây là phần bạn có thể chuẩn bị kỹ nhất.

"Bạn đã từng test app/website nào chưa?"

Nếu chưa có kinh nghiệm làm việc thực tế: đừng nói "chưa". Thay vào đó, kể về dự án tự học:

• "Em đã tự test trang đăng ký của Shopee và viết khoảng 15 test case..."
• "Em tham gia 1 dự án nhỏ của nhóm học, test tính năng giỏ hàng..."
• "Em đã thực hành test trên demo app của khóa học..."

Nhà tuyển dụng đánh giá cao bạn tự học có hệ thống hơn bạn chỉ đọc lý thuyết.

Dự án tự học nhỏ vẫn tốt hơn không có gì để kể

"Bạn dùng tool gì để test?"

Với manual tester junior, danh sách phổ biến:

• Jira: Quản lý bug và task
• Postman: Test API cơ bản
• Chrome DevTools: Inspect element, check network, console lỗi
• Excel/Google Sheets: Viết test case nếu chưa có TestRail
• TestRail/Qase: Quản lý test case (biết là plus)

Nếu bạn chưa dùng Jira hay Postman, tải về và thực hành thử trước khi phỏng vấn. Không cần thành thạo, nhưng biết giao diện cơ bản là cộng điểm.

"Điểm mạnh và điểm yếu của bạn trong testing là gì?"

Câu hỏi này cần trả lời thật - không nên nói "em tỉ mỉ" rồi thôi. Cần ví dụ cụ thể:

• "Điểm mạnh của em là kiên nhẫn với edge case - em hay test thêm 2-3 trường hợp bất thường mà người khác bỏ qua."
• "Điểm yếu là em test hơi chậm vì muốn kỹ - em đang học cách ưu tiên test case theo risk để cân bằng."

Nói điểm yếu thật nhưng kèm cách bạn đang cải thiện. Đừng nói "em không có điểm yếu" - không ai tin.

Nếu bạn đang tìm dự án để thực hành, có thể tham khảo các app demo trên các platform học online để lấy môi trường test thực tế.

Câu hỏi về SQL cơ bản

Đây là phần bất ngờ với nhiều bạn: phần lớn job description tester tại Việt Nam yêu cầu biết SQL cơ bản. Không phải viết stored procedure hay tối ưu query - chỉ cần đọc được data từ database để verify kết quả test.

"Bạn có biết SQL không?"

Nếu biết: kể ngay ví dụ bạn đã dùng SQL để làm gì trong testing. Ví dụ: "Em dùng SELECT để kiểm tra sau khi đặt hàng thành công, record có lưu đúng vào bảng orders không."

Nếu chưa biết: thừa nhận thẳng nhưng thêm "Em đang học, đã biết SELECT, WHERE cơ bản."

Câu hỏi SQL thường gặp:

-- Tìm tất cả user có email chứa '@gmail.com'
SELECT * FROM users WHERE email LIKE '%@gmail.com';

-- Đếm số đơn hàng trạng thái 'pending'
SELECT COUNT(*) FROM orders WHERE status = 'pending';

-- Lấy 10 đơn hàng gần nhất
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;

Biết SQL cơ bản giúp verify data nhanh hơn thay vì chờ dev kiểm tra hộ

Bạn không cần học sâu JOIN hay subquery ngay. Nhưng SELECT, WHERE, COUNT, ORDER BY là bộ tứ bắt buộc phải biết trước phỏng vấn tester junior.

Luyện SQL miễn phí tại luyện SQL cơ bản miễn phí - chỉ cần 2-3 tiếng là nắm được phần cơ bản dùng cho testing.