Phỏng vấn Fresher Tester: 25 câu hỏi thường gặp và cách trả lời thực tế
một tháng trước · 22 phút đọc
Trước khi vào phòng phỏng vấn
Mình nhớ lần đầu phỏng vấn tester, chuẩn bị cả tuần nhưng vào phòng vẫn blank hết. Không phải vì không biết - mà vì không biết họ muốn nghe gì. Cùng một câu hỏi "test case là gì?", trả lời theo sách khác hoàn toàn so với trả lời như người đã từng viết test case thật.
Bài này mình tổng hợp 25 câu hỏi phỏng vấn fresher tester hay gặp nhất, chia thành 4 nhóm rõ ràng. Mỗi câu mình giải thích tại sao nhà tuyển dụng hỏi, cách trả lời ghi điểm, và những gì nên tránh. Mục tiêu không phải học thuộc lòng, mà hiểu để trả lời tự nhiên bằng lời của bạn.
Chuẩn bị kỹ trước phỏng vấn - hiểu tại sao họ hỏi quan trọng hơn học thuộc câu trả lời
Thấy danh sách 25 câu có vẻ nhiều, nhưng đừng lo. Phần lớn câu hỏi xoay quanh 3-4 chủ đề cốt lõi. Nắm được tư duy là bạn tự suy ra cách trả lời, không cần nhớ từng từ.
Nhóm 1: Câu hỏi về bản thân (5 câu)
Nhóm này không phải test kiến thức, mà test xem bạn có phù hợp văn hóa công ty và hiểu bản thân không. Nhiều fresher bỏ qua chuẩn bị phần này - sai lầm lớn.
Câu hỏi bản thân tưởng dễ nhưng dễ bị loại nhất nếu trả lời chung chung
Câu 1: Tại sao bạn muốn làm tester?
Họ muốn biết gì: Bạn chọn nghề có lý do hay chỉ vì "không biết làm gì". Fresher trái ngành cần thuyết phục hơn người học IT.
Cách trả lời tốt: Kết hợp điểm mạnh cá nhân + lý do cụ thể. "Mình làm kế toán 3 năm, thấy mình hay để ý lỗi trong báo cáo, tìm ra sai số mà người khác bỏ qua. Khi tìm hiểu về testing, mình nhận ra tư duy tỉ mỉ đó chính xác là thứ tester cần. Mình muốn dùng kỹ năng đó trong môi trường tech."
Tránh: "Vì lương cao" hoặc "Vì không cần code" - những lý do này cho thấy bạn chưa hiểu nghề.
Câu 2: Điểm mạnh của bạn khi làm tester là gì?
Họ muốn biết gì: Self-awareness. Bạn có biết mình phù hợp với nghề ở điểm nào không.
Cách trả lời tốt: Chọn 1-2 điểm mạnh thật sự liên quan đến testing, kèm ví dụ cụ thể. "Mình tỉ mỉ và kiên nhẫn với chi tiết. Ví dụ khi tự học, mình viết test case cho trang đăng nhập Jira demo, tìm được 12 test case thay vì 4-5 cái thông thường vì mình xét cả edge case như password có emoji."
Tránh: Liệt kê dài dòng không dẫn chứng. "Mình tỉ mỉ, cẩn thận, chăm chỉ, trách nhiệm..." - ai cũng nói vậy.
Câu 3: Điểm yếu của bạn là gì?
Họ muốn biết gì: Bạn có tự nhận thức không, và có đang cải thiện không.
Cách trả lời tốt: Nêu điểm yếu thật nhưng không chết người với testing, kèm cách đang xử lý. "Mình hay muốn test quá kỹ, đôi khi mất nhiều thời gian hơn cần thiết. Mình đang học cách ưu tiên: test những path quan trọng nhất trước, edge case sau khi còn thời gian."
Tránh: "Mình không có điểm yếu" hoặc điểm yếu chết người với nghề như "mình hay quên và thiếu kiên nhẫn".
Câu 4: Bạn biết gì về công ty chúng tôi?
Họ muốn biết gì: Bạn có thật sự muốn làm ở đây không, hay apply hàng loạt.
Cách trả lời tốt: Nghiên cứu website, sản phẩm, tin tức công ty trước. Nêu 2-3 điểm cụ thể: sản phẩm họ làm, thị trường, điểm nổi bật. "Mình biết [tên công ty] đang phát triển app quản lý nhà hàng, hiện có khoảng X nghìn người dùng. Mình thấy thú vị vì đây là sản phẩm B2B, testing sẽ cần hiểu nghiệp vụ nhà hàng sâu hơn."
Tránh: Đọc vanh vách từ Wikipedia mà không có nhận xét gì.
Câu 5: Bạn kỳ vọng gì sau 6 tháng - 1 năm làm việc?
Họ muốn biết gì: Mục tiêu bạn có realistic không, bạn nghĩ dài hạn không.
Cách trả lời tốt: Kỳ vọng phát triển kỹ năng cụ thể, không phải nhảy vọt. "Mình muốn thành thạo manual testing, tự tin viết test case cho các tính năng phức tạp và viết bug report rõ ràng không cần hỏi lại. Sau 1 năm muốn bắt đầu tìm hiểu automation testing."
Tránh: "Mình muốn thăng chức" hoặc kỳ vọng quá ảo.
Nhóm 2: Câu hỏi về kiến thức cơ bản (8 câu)
Đây là nhóm fresher hay lo nhất. Nhưng mình nói thật: họ không kỳ vọng bạn trả lời như senior. Họ cần biết bạn hiểu đúng khái niệm cơ bản, không học vẹt.
Câu 6: Tester/QA làm gì trong dự án?
Họ muốn biết gì: Bạn có hiểu vai trò thật sự của tester không, hay chỉ nghĩ "tìm bug".
Cách trả lời tốt: "Tester tham gia từ giai đoạn đầu: đọc requirement để tìm điểm mơ hồ, viết test case, thực thi test, báo cáo bug, và verify lại sau khi dev fix. Mục tiêu không phải tìm nhiều bug nhất, mà đảm bảo sản phẩm đến tay người dùng với chất lượng tốt nhất có thể."
Tránh: "Tester tìm lỗi trong phần mềm" - quá đơn giản và không thể hiện được hiểu sâu.
Câu 7: Test case là gì? Cho ví dụ.
Họ muốn biết gì: Bạn có thực sự biết viết test case không, hay chỉ biết định nghĩa.
Cách trả lời tốt: Định nghĩa ngắn + ví dụ cụ thể. "Test case là kịch bản mô tả bước thực hiện và kết quả mong đợi để kiểm tra một chức năng. Ví dụ test case đăng nhập: Bước 1 - mở trang đăng nhập, Bước 2 - nhập email hợp lệ và password đúng, Bước 3 - bấm Đăng nhập. Kết quả mong đợi: chuyển về trang dashboard. Với trường hợp sai password thì kết quả mong đợi là hiển thị thông báo lỗi."
Tránh: Định nghĩa sách giáo khoa không có ví dụ.
Câu 8: Bug/defect là gì? Phân biệt bug và defect.
Họ muốn biết gì: Bạn nắm được khái niệm hay không. (Lưu ý: trong thực tế nhiều team dùng bug và defect như nhau.)
Cách trả lời tốt: "Bug là lỗi phát hiện trong quá trình testing, còn defect thường dùng để chỉ lỗi sau khi sản phẩm release. Trong thực tế đi làm, hai từ này hay được dùng thay nhau. Quan trọng hơn là biết mô tả lỗi rõ ràng để dev tái hiện được."
Câu 9: Vòng đời của bug (bug life cycle) là gì?
Họ muốn biết gì: Bạn biết quy trình xử lý bug trong team như thế nào.
Cách trả lời tốt: Đi qua các trạng thái chính. "Bug bắt đầu ở trạng thái New khi tester báo cáo. QA lead hoặc PM review và Assign cho dev. Dev sửa xong chuyển sang Fixed. Tester kiểm tra lại: nếu đúng thì Closed, nếu vẫn lỗi thì Reopen. Ngoài ra còn có Rejected (dev cho là không phải bug) hoặc Duplicate."
Bug life cycle - quy trình quan trọng tester nào cũng phải nắm
Câu 10: Phân biệt kiểm thử chức năng và phi chức năng (functional và non-functional testing)?
Cách trả lời tốt: "Kiểm thử chức năng (functional testing) kiểm tra hệ thống làm đúng chức năng không, ví dụ: button thanh toán có xử lý đúng không. Kiểm thử phi chức năng (non-functional testing) kiểm tra các yếu tố khác như hiệu suất (performance) - app tải trong bao nhiêu giây, bảo mật, khả năng chịu tải. Fresher thường làm functional testing trước."
Câu 11: Smoke testing là gì? Khi nào dùng?
Cách trả lời tốt: Giải thích + ví dụ ví von dễ hiểu. "Smoke testing - kiểm thử khói - là bước test nhanh các chức năng cốt lõi nhất để xem build mới có đủ ổn định để test sâu hơn không. Giống như bạn bật điện thoại lên xem sáng màn hình không trước khi check các tính năng khác. Nếu smoke testing fail thì trả build lại cho dev ngay, không test tiếp."
Câu 12: Regression testing là gì? Tại sao quan trọng?
Cách trả lời tốt: "Kiểm thử hồi quy (regression testing) là test lại các tính năng cũ sau khi dev thay đổi code, để đảm bảo thay đổi mới không làm hỏng thứ đang chạy tốt. Ví dụ: dev fix bug ở trang thanh toán, mình cần test lại giỏ hàng, trang sản phẩm, lịch sử đơn hàng. Mình từng skip bước này vì nghĩ 'fix nhỏ thôi' - kết quả là tính năng voucher bị hỏng, không ai phát hiện đến lúc khách báo."
Câu 13: Black box testing và white box testing khác nhau thế nào?
Cách trả lời tốt: "Black box testing: tester test mà không biết code bên trong, chỉ test từ góc độ người dùng - nhập input, kiểm tra output. White box testing: tester biết code và test dựa trên logic bên trong. Fresher tester thường làm black box là chính, vì không cần biết code vẫn test được. Hiểu white box thêm thì tốt nhưng không bắt buộc ngay từ đầu."
Yên tâm nếu bạn chưa nắm hết các loại testing này. Mình cũng mất vài tháng đầu mới quen. Đi làm thực tế, bạn sẽ dùng đi dùng lại một vài loại rồi tự khắc nhớ.
Nhóm 3: Câu hỏi về kỹ năng thực tế (7 câu)
Nhóm này quan trọng nhất với fresher. Nhà tuyển dụng muốn biết bạn có thể làm việc thật ngay từ ngày đầu không. Càng có ví dụ từ dự án tự học, bạn càng ghi điểm.
Câu 14: Bạn viết test case như thế nào?
Họ muốn biết gì: Quy trình tư duy của bạn khi viết test case.
Cách trả lời tốt: "Mình bắt đầu bằng đọc kỹ requirement để hiểu tính năng làm gì, người dùng dùng như thế nào. Sau đó chia thành 3 nhóm: happy path (luồng đúng), negative case (input sai, thiếu), edge case (giá trị biên, ký tự đặc biệt). Với trang đăng nhập, mình sẽ test email hợp lệ/không hợp lệ, password đúng/sai/để trống, đăng nhập nhiều lần liên tiếp, copy-paste password..."
Tránh: "Mình đọc requirement rồi viết" - quá chung chung.
Câu 15: Một bug report tốt cần có gì?
Cách trả lời tốt: Liệt kê + giải thích tại sao từng phần quan trọng.
"Bug report tốt cần:
- Tiêu đề rõ: nói ngay hành động - kết quả - thứ bị sai. Ví dụ: 'Nhập email thiếu @ vẫn đăng nhập được'
- Môi trường: trình duyệt, hệ điều hành, version
- Bước tái hiện: từng bước cụ thể, ai cũng làm theo được
- Kết quả thực tế vs kết quả mong đợi: so sánh rõ
- Severity/Priority: mức độ nghiêm trọng
- Ảnh chụp màn hình hoặc video ngắn
Thiếu bước tái hiện rõ ràng là lỗi phổ biến nhất. Dev không tái hiện được bug = không fix được."
Bug report rõ ràng giúp dev fix nhanh hơn - đây là kỹ năng cốt lõi của tester
Câu 16: Bạn có dùng Jira không? Mô tả quy trình làm việc với Jira.
Cách trả lời tốt (nếu đã học): "Mình đã tự học dùng Jira qua tài khoản free. Khi tìm bug, mình tạo issue mới, chọn type là Bug, điền tiêu đề, mô tả, steps to reproduce, ảnh đính kèm, đặt severity và assign cho dev phụ trách. Theo dõi status trên board để biết bug đang ở giai đoạn nào."
Cách trả lời tốt (nếu chưa dùng Jira): "Mình chưa có cơ hội dùng Jira trong dự án thật, nhưng mình đã tự tạo tài khoản và thực hành. Mình hiểu quy trình: tạo issue, assign, theo dõi status. Mình tin mình học nhanh khi có môi trường làm việc."
Tránh: Nói "chưa dùng bao giờ" rồi thôi, không có kế hoạch học.
Câu 17: Bạn ưu tiên test gì trước khi thời gian bị hạn chế?
Họ muốn biết gì: Tư duy risk-based testing của bạn.
Cách trả lời tốt: "Mình ưu tiên theo mức độ rủi ro: tính năng core (đăng nhập, thanh toán) trước, sau đó tính năng hay dùng nhất, cuối cùng mới là tính năng phụ. Nếu là bản cập nhật, mình test phần thay đổi + regression nhanh cho các phần liên quan. Không bao giờ skip test tính năng thanh toán dù thiếu thời gian - lỗi ở đây ảnh hưởng trực tiếp doanh thu."
Câu 18: Bạn viết test case dựa trên tài liệu nào?
Cách trả lời tốt: "Tài liệu chính là software requirement specification (SRS) hoặc user story. Mình cũng tham khảo wireframe/mockup để biết UI trông thế nào. Nếu không có tài liệu đầy đủ, mình hỏi BA hoặc PM trước khi viết, để tránh viết test case sai hướng phải làm lại."
Câu 19: Mô tả quy trình bạn sẽ test tính năng đăng ký tài khoản.
Đây là câu test tư duy thực chiến - quan trọng.
Cách trả lời tốt: "Đầu tiên mình đọc requirement xem field nào bắt buộc, điều kiện hợp lệ của từng field. Sau đó test theo 3 nhóm: Happy path - điền đầy đủ thông tin hợp lệ, submit thành công. Negative - email sai format, password quá ngắn, bỏ trống field bắt buộc, email đã tồn tại. Edge case - tên có ký tự đặc biệt, password giới hạn ký tự tối đa, copy-paste email có khoảng trắng đầu cuối. Cuối cùng test trên nhiều trình duyệt và màn hình."
Câu 20: Severity và Priority khác nhau thế nào?
Cách trả lời tốt: "Severity là mức độ nghiêm trọng về mặt kỹ thuật: bug làm crash app, mất dữ liệu thì severity cao. Priority là mức độ ưu tiên cần fix: bug nhỏ nhưng nằm ở trang chủ, nhiều người thấy thì priority cao dù severity thấp. Hai chỉ số này không nhất thiết đi cùng nhau. Bug typography sai ở màn hình chính: severity thấp nhưng priority cao vì ảnh hưởng uy tín."
Nếu bạn chưa có kinh nghiệm thực tế với Jira hay các tool quản lý bug, mình khuyên bạn tạo tài khoản Jira free và tự thực hành trước khi phỏng vấn. 30 phút thực hành giá trị hơn 3 tiếng đọc lý thuyết.
Nhóm 4: Câu hỏi tình huống (5 câu)
Câu hỏi tình huống (behavioral/situational questions) là thứ phân biệt người chỉ học lý thuyết với người thật sự tư duy như tester. Không có đáp án duy nhất đúng, nhưng có cách trả lời thể hiện tư duy tốt hơn.
Câu tình huống kiểm tra tư duy thực tế - không có đáp án sách vở
Câu 21: Bạn tìm thấy bug nhưng dev nói đó không phải bug. Bạn làm gì?
Họ muốn biết gì: Bạn có biết xử lý conflict chuyên nghiệp không, tránh drama.
Cách trả lời tốt: "Đầu tiên mình kiểm tra lại: có thể mình hiểu sai requirement? Mình xem lại tài liệu, reproduce lại từng bước. Nếu vẫn thấy đây là bug, mình đối chiếu với requirement và chỉ ra cụ thể 'theo tài liệu X, behavior mong đợi là Y, nhưng thực tế là Z'. Nếu vẫn không đồng ý, mình escalate lên BA hoặc PM để clarify requirement, không cãi nhau với dev. Bằng chứng rõ ràng quan trọng hơn cảm giác."
Tránh: "Mình sẽ cãi đến cùng vì mình đúng" hoặc "Mình chấp nhận luôn để không mất lòng".
Câu 22: Requirement mơ hồ, không rõ, bạn làm gì?
Cách trả lời tốt: "Mình ghi lại tất cả các điểm chưa rõ, sau đó hỏi BA hoặc PM - hỏi tập trung một lần thay vì hỏi rải rác làm phiền. Mình đề xuất cách hiểu của mình: 'Theo mình hiểu thì X, có đúng không?' để họ confirm hoặc correct. Không bao giờ tự mình đoán rồi viết test case, vì đoán sai thì toàn bộ test phải làm lại."
Câu 23: Bạn sẽ làm gì nếu deadline sắp đến nhưng còn nhiều test case chưa chạy?
Cách trả lời tốt: "Báo cáo trạng thái ngay cho lead: đã test được bao nhiêu, còn bao nhiêu, cần thêm bao lâu. Cùng với lead quyết định ưu tiên: test case nào bắt buộc phải xong, test case nào có thể defer. Không tự mình im lặng rồi rush qua cho xong - rush testing tạo ra bug chưa tìm thấy, nguy hiểm hơn là delay."
Tránh: "Mình sẽ test nhanh hơn để kịp" - câu này cho thấy bạn sẵn sàng hy sinh chất lượng.
Câu 24: Bạn phát hiện bug nghiêm trọng ngay trước khi release. Bạn xử lý thế nào?
Cách trả lời tốt: "Báo ngay lập tức - không chờ meeting tiếp theo. Ghi bug report đầy đủ và reproduce rõ ràng. Xác định severity: bug này có block release không, hay có workaround tạm? Báo cáo cho lead và PM để team quyết định: delay release, fix gấp, hay release với known issue và hotfix sau. Quyết định đó là của team, không phải của mình một mình. Mình chỉ đảm bảo thông tin rõ ràng để họ quyết định đúng."
Câu 25: Bạn test một tính năng, nhưng không có document. Bạn làm sao?
Cách trả lời tốt: "Mình dùng nhiều nguồn để hiểu tính năng: hỏi BA/PM về mục đích tính năng, xem wireframe hoặc prototype nếu có, dùng kinh nghiệm người dùng thông thường để suy ra behavior mong đợi. Mình có thể dùng exploratory testing - khám phá tự do dựa trên hiểu biết về ứng dụng. Ghi lại giả định mình đang dùng để sau này trace lại nếu cần."
Exploratory testing - kiểm thử khám phá - là kỹ năng tester giỏi cần có. Không phải lúc nào cũng có tài liệu đầy đủ, và tester biết xử lý situation này rất được đánh giá cao.
Mẹo chung để ghi điểm trong phỏng vấn tester
Biết câu trả lời chỉ là điều kiện cần. Điều kiện đủ là truyền đạt được tư duy.
Dùng cấu trúc STAR khi cần: Situation - Task - Action - Result. Đặc biệt hữu ích với câu hỏi tình huống: mô tả bối cảnh, nhiệm vụ, hành động bạn thực hiện, kết quả đạt được.
Luôn kèm ví dụ cụ thể. Nếu bạn đã tự học và có dự án thực hành, đây là lúc nhắc đến. "Mình đã thực hành viết test case cho trang đăng nhập và tìm được X test case" thuyết phục hơn nhiều so với chỉ định nghĩa.
Thừa nhận nếu không biết - nhưng kèm thái độ học hỏi. "Mình chưa có kinh nghiệm thực tế với performance testing, nhưng mình đã đọc cơ bản về JMeter và hiểu nó dùng để test gì. Mình sẵn sàng học sâu hơn khi có cơ hội." Trung thực + proactive luôn tốt hơn bịa.
Hỏi lại cuối buổi phỏng vấn. Chuẩn bị 2-3 câu hỏi thật sự: team dùng công cụ nào để quản lý test case, quy trình onboarding fresher như thế nào, team size và cách team phân công công việc. Câu hỏi thông minh cho thấy bạn nghĩ đến việc làm thật sự, không chỉ cần việc.
Thái độ học hỏi và trả lời trung thực thuyết phục hơn trả lời thuộc lòng
Mình muốn nhấn mạnh điều này: fresher không ai kỳ vọng bạn biết hết. Điều nhà tuyển dụng thật sự đánh giá là tư duy tỉ mỉ, thái độ cẩn thận, và khả năng học nhanh. Bạn đọc đến đây nghĩa là bạn đang chuẩn bị nghiêm túc - đó đã là lợi thế so với nhiều ứng viên khác.
Tóm lại, để phỏng vấn tốt:
- Hiểu tại sao nhà tuyển dụng hỏi từng câu - đừng học thuộc lòng
- Kèm ví dụ từ dự án tự học của bạn
- Thừa nhận điều chưa biết nhưng cho thấy bạn đang học
- Chuẩn bị câu hỏi ngược để hỏi lại
- Thể hiện tư duy: tỉ mỉ, cẩn thận, không rush
Bạn cần tải bộ câu hỏi ôn tập tổng hợp để tự luyện trước buổi phỏng vấn? Mình đã tạo sẵn bên dưới: Tải bộ câu hỏi ôn tập phỏng vấn tester
Comment bên dưới nếu bạn có câu hỏi nào thêm hoặc muốn mình giải thích kỹ hơn câu nào. Chúc bạn phỏng vấn thành công!