Câu hỏi phỏng vấn Tester thường gặp & cách trả lời

Nhà tuyển dụng thực sự đánh giá điều gì?

Với vị trí fresher và junior, người phỏng vấn không kỳ vọng bạn biết nhiều. Họ kiểm tra ba thứ: bạn có tư duy đặt câu hỏi có hệ thống không, bạn diễn đạt có rõ ràng không, và bạn có tự học được không.

Nhóm câu hỏi	Tỉ trọng thường gặp	Thứ đang được đo
Lý thuyết kiểm thử	~30%	Nền tảng có vững, thuật ngữ có chuẩn không
Bài tập thiết kế test case tại chỗ	~35%	Tư duy thật — phần quyết định đậu/trượt
Tình huống dự án	~20%	Cách làm việc với người khác, xử lý xung đột
Động lực và định hướng	~15%	Có gắn bó lâu dài không

Nhóm 1 — Câu hỏi lý thuyết và cách trả lời

"Kiểm thử phần mềm là gì? Mục đích của kiểm thử?"

Trả lời ngắn: kiểm thử là hoạt động đánh giá sản phẩm để phát hiện khiếm khuyết và cung cấp thông tin về chất lượng cho người ra quyết định. Điểm cộng nếu bạn nói thêm: kiểm thử không chứng minh được phần mềm không có lỗi, nên mục tiêu thực tế là giảm rủi ro xuống mức chấp nhận được.

"Phân biệt QA và QC / QA và Tester"

QA hướng vào quy trình để ngăn lỗi phát sinh; QC hướng vào sản phẩm để phát hiện lỗi đã có. Nói thêm rằng ở Việt Nam hai chức danh này thường được dùng thay thế nhau trong tin tuyển dụng cho thấy bạn hiểu thực tế thị trường, không chỉ hiểu sách.

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

Severity là mức nghiêm trọng kỹ thuật, tester đánh giá. Priority là mức khẩn cấp cần sửa, do nghiệp vụ quyết định. Luôn đưa ví dụ cặp lệch nhau: lỗi sai chính tả tên công ty trên trang chủ có severity thấp nhưng priority cao.

"Smoke test, sanity test và regression test khác gì nhau?"

Loại	Phạm vi	Thời điểm	Câu trả lời quyết định
Smoke	Rộng, nông	Ngay khi nhận build	Build này có đáng test tiếp không?
Sanity	Hẹp, sâu	Sau một bản vá nhỏ	Vùng vừa sửa đã đúng chưa?
Regression	Rộng, sâu	Trước khi phát hành	Thay đổi có phá vỡ thứ cũ không?

"Bạn biết những kỹ thuật thiết kế test case nào?"

Kể tên phân vùng tương đương, phân tích giá trị biên, bảng quyết định, kiểm thử chuyển trạng thái — rồi chọn một kỹ thuật và giải một ví dụ ngắn ngay tại chỗ. Người phỏng vấn gần như luôn hỏi tiếp "cho ví dụ đi", nên chủ động làm trước sẽ ghi điểm.

Nhóm 2 — Bài tập thiết kế test case tại chỗ

Đây là phần quyết định. Dạng phổ biến nhất: "Hãy test ô nhập số điện thoại", "Hãy test chức năng đăng nhập", "Hãy test cái bút này", "Hãy test chức năng chuyển tiền".

Khung trả lời 5 bước dùng được cho mọi đề

Hỏi lại trước khi trả lời. "Ô số điện thoại này chỉ nhận số Việt Nam hay cả quốc tế? Có bắt buộc không? Độ dài quy định là bao nhiêu?" Việc hỏi lại chính là điểm cộng lớn nhất — nó cho thấy bạn không test một yêu cầu mơ hồ.
Nêu khung phân loại: em sẽ chia thành trường hợp hợp lệ, không hợp lệ và giá trị biên.
Liệt kê có cấu trúc theo từng nhóm, không nhảy cóc lung tung.
Bổ sung nhóm phi chức năng: bảo mật, hiệu năng, khả năng dùng trên di động, hỗ trợ tiếng Việt có dấu.
Kết lại bằng ưu tiên: nếu chỉ có nửa ngày, em sẽ tập trung vào nhóm nào và vì sao.

Ví dụ: test ô nhập số điện thoại

Nhóm	Trường hợp kiểm thử
Hợp lệ	0912345678 (10 số, đầu số hợp lệ); +84912345678 nếu chấp nhận định dạng quốc tế
Biên	9 số, 10 số, 11 số; đầu số vừa được cấp mới; số bắt đầu bằng 0 và không bắt đầu bằng 0
Không hợp lệ	Bỏ trống; chứa chữ cái; chứa khoảng trắng; ký tự đặc biệt; số âm; toàn số 0
Định dạng	Có dấu chấm hoặc gạch ngang: 091.234.5678; có khoảng trắng đầu/cuối
Bảo mật	Chuỗi SQL injection; chuỗi script; chuỗi cực dài 10.000 ký tự
Giao diện	Bàn phím số có tự bật trên di động không; dán từ clipboard; tự động cắt khoảng trắng
Nghiệp vụ	Số đã tồn tại trong hệ thống; số đã bị khoá; số vừa bị xoá

Dạng đề "test một vật thể ngoài đời"

Với đề kiểu "test cái bút", "test cái thang máy", "test cái máy ATM": người phỏng vấn đang đo khả năng tư duy có hệ thống chứ không đo kiến thức. Hãy trả lời theo trục: chức năng chính, điều kiện biên, môi trường sử dụng, đối tượng người dùng, độ bền, an toàn, trải nghiệm.

Nhóm 3 — Câu hỏi tình huống

"Dev nói đây không phải bug, bạn xử lý thế nào?"

Trả lời theo hướng dựa vào bằng chứng, không dựa vào cảm tính hay hơn thua: đối chiếu lại tài liệu yêu cầu. Nếu tài liệu nói rõ thì đưa ra dẫn chứng. Nếu tài liệu không nói rõ thì đây là lỗ hổng ở tầng yêu cầu, cần đưa BA hoặc chủ sản phẩm vào để quyết định — chứ không phải tranh luận tay đôi.

"Sắp đến hạn phát hành mà bạn chưa test xong thì làm gì?"

Câu này đo tư duy dựa trên rủi ro. Trả lời: em sẽ báo sớm chứ không giấu, đồng thời trình bày rõ phần nào đã test, phần nào chưa, và rủi ro của phần chưa test là gì — để quản lý ra quyết định phát hành hay lùi lịch. Nhấn mạnh: tester cung cấp thông tin, người ra quyết định là quản lý sản phẩm.

"Bug lọt ra production, bạn làm gì?"

Ưu tiên xác định mức ảnh hưởng và báo ngay cho những người liên quan.
Hỗ trợ tái hiện để đội sửa nhanh nhất có thể.
Sau khi xử lý xong, phân tích vì sao bộ test hiện tại không bắt được — thiếu test case, thiếu dữ liệu, hay môi trường test khác production.
Bổ sung test case cho tình huống đó vào bộ regression để không lặp lại.

"Bạn không tái hiện được bug người dùng báo thì sao?"

Nêu quy trình: thu thập thêm thông tin môi trường, tài khoản, thời điểm, các bước; xem log và dữ liệu ở thời điểm đó; thử trên đúng cấu hình của người dùng. Đề cập việc dùng SQL để kiểm tra dữ liệu thực tế sẽ tạo ấn tượng rất tốt.

Câu hỏi dành riêng cho người trái ngành

"Vì sao bạn chuyển từ ngành cũ sang làm tester?"

Tránh hai câu trả lời khiến bạn mất điểm ngay: "vì lương IT cao" và "vì em nghe nói tester dễ vào nhất". Hãy nối nghề cũ với nghề mới: bạn đã từng làm việc đòi hỏi tỉ mỉ, phát hiện sai sót, hoặc hiểu quy trình nghiệp vụ — và đó chính là chất liệu của nghề kiểm thử.

"Bạn chưa có kinh nghiệm dự án, làm sao chứng minh năng lực?"

Đây là lúc portfolio cứu bạn: một bộ test case bạn tự viết cho một ứng dụng thật, một danh sách bug bạn tự tìm được kèm ảnh chụp, một bảng quyết định cho một luồng nghiệp vụ. Mang theo và chủ động đưa ra. Nó thay thế được kinh nghiệm dự án ở vòng fresher.

Câu hỏi bạn nên hỏi lại nhà tuyển dụng

Không hỏi gì là một trong những lý do trượt phổ biến nhất — nó bị đọc là thiếu quan tâm. Chuẩn bị sẵn ba câu:

Đội hiện tại có bao nhiêu tester và quy trình kiểm thử đang chạy theo mô hình nào?
Sản phẩm em sẽ test thuộc lĩnh vực nghiệp vụ nào, và người mới thường mất bao lâu để nắm được nghiệp vụ đó?
Trong sáu tháng đầu, công ty kỳ vọng một người ở vị trí này làm được gì?

Checklist chuẩn bị trước buổi phỏng vấn

Ôn lại các cặp thuật ngữ dễ lẫn: severity/priority, smoke/sanity, verification/validation, test case/test scenario.
Luyện giải ít nhất 5 đề thiết kế test case tại chỗ, bấm giờ 10 phút mỗi đề.
Chuẩn bị portfolio: bộ test case, danh sách bug, bảng quyết định.
Chuẩn bị một câu chuyện cụ thể cho mỗi câu tình huống, theo cấu trúc bối cảnh – việc cần làm – hành động – kết quả.
Đọc kỹ mô tả công việc, tra trước lĩnh vực nghiệp vụ của công ty.
Chuẩn bị 3 câu hỏi ngược.

HỎI ĐÁP

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

Phỏng vấn tester fresher thường hỏi những gì?

Chủ yếu bốn nhóm: lý thuyết kiểm thử cơ bản, bài tập thiết kế test case tại chỗ, câu hỏi tình huống về cách phối hợp với đội phát triển, và câu hỏi về động lực nghề nghiệp. Bài tập thiết kế test case tại chỗ là phần quyết định đậu hay trượt.

Chưa có kinh nghiệm dự án thì trả lời phỏng vấn tester thế nào?

Thay kinh nghiệm dự án bằng bằng chứng cụ thể: bộ test case bạn tự viết cho một ứng dụng thật, danh sách bug tự tìm được kèm ảnh chụp màn hình, hoặc một bảng quyết định cho luồng nghiệp vụ. Ở vòng fresher, portfolio tự làm có sức thuyết phục tương đương kinh nghiệm.

Gặp câu "hãy test cái bút này" thì trả lời ra sao?

Người phỏng vấn đang đo tư duy có hệ thống, không đo kiến thức. Trả lời theo trục: chức năng chính, điều kiện biên, môi trường sử dụng, đối tượng người dùng, độ bền, an toàn và trải nghiệm. Bắt đầu bằng việc hỏi lại yêu cầu sẽ ghi điểm ngay.

Có nên nói thẳng là mình chuyển ngành vì lương IT cao không?

Không nên đặt đó làm lý do chính, vì nó gợi ý bạn sẽ rời đi khi có nơi trả cao hơn. Hãy nối nghề cũ với nghề mới: chỉ ra kỹ năng tỉ mỉ, hiểu quy trình nghiệp vụ hoặc khả năng diễn đạt từ công việc trước chính là chất liệu của nghề kiểm thử.