20+ Câu hỏi phỏng vấn Fresher Tester thường gặp & Cách trả lời câu hỏi 'Tại sao chuyển nghề?'
2 tháng trước · 20 phút đọc
Trước khi vào phòng phỏng vấn
Mình nhớ lần phỏng vấn tester đầu tiên - ngồi chờ ngoài hành lang, tay cầm tờ giấy ghi chú đủ thứ, đầu thì trống rỗng. HR hỏi "Bạn hiểu bug life cycle là gì không?", mình ú ớ mất 30 giây. Không phải vì không biết, mà vì không chuẩn bị cách diễn đạt.
Phỏng vấn tester fresher khác với phỏng vấn dev ở chỗ: HR không kỳ vọng bạn biết mọi thứ. Họ muốn thấy tư duy logic, sự tỉ mỉ, và thái độ học hỏi. Đặc biệt nếu bạn đang chuyển từ ngành khác sang, câu hỏi về "tại sao chuyển" sẽ gần như chắc chắn xuất hiện.
Bài này mình tổng hợp 20+ câu hỏi phỏng vấn fresher tester mình thấy xuất hiện nhiều nhất ở các công ty Việt Nam, kèm cách trả lời để bạn không bị bất ngờ.
Chuẩn bị kỹ hơn phỏng vấn, tự tin hơn khi vào phòng
Bài được chia làm 4 nhóm câu hỏi:
- Nhóm 1: Khái niệm cơ bản (HR kiểm tra nền tảng)
- Nhóm 2: Kỹ năng thực hành (HR kiểm tra bạn có biết làm không)
- Nhóm 3: Tư duy và xử lý tình huống
- Nhóm 4: Câu hỏi cá nhân - bao gồm "Tại sao chuyển nghề?"
Nhóm 1: Câu hỏi khái niệm cơ bản
Đây là nhóm HR hỏi đầu tiên để "warm up" và đánh giá bạn có nền tảng không. Đừng trả lời kiểu sách giáo khoa, hãy giải thích bằng lời của mình.
Giải thích bằng lời mình > đọc lại định nghĩa sách
Câu 1: Tester/QA là gì? Công việc hàng ngày gồm những gì?
HR muốn gì: Kiểm tra bạn hiểu nghề, không chỉ "nghe nói tester dễ xin việc".
Đáp án mẫu tốt: "Tester là người kiểm thử phần mềm để tìm lỗi trước khi người dùng thật gặp phải. Công việc hàng ngày gồm đọc yêu cầu tính năng, viết test case (kịch bản kiểm thử), chạy test, và log bug - tức ghi lại lỗi tìm được để dev fix. Ngoài ra còn regression testing - kiểm tra lại tính năng cũ sau khi dev sửa, đảm bảo không hỏng thêm."
Lỗi cần tránh: Nói "Tester là người tìm bug" rồi dừng lại. Vậy quá ngắn, HR sẽ nghĩ bạn chưa tìm hiểu đủ.
Câu 2: Bug life cycle (vòng đời bug) là gì?
HR muốn gì: Xem bạn có nắm quy trình làm việc thực tế không.
Đáp án mẫu tốt: "Bug đi qua các trạng thái: New (tester tìm ra và log) → Assigned (quản lý giao cho dev) → In Progress (dev đang fix) → Fixed (dev fix xong) → Retest (tester kiểm tra lại) → Closed (đã ổn) hoặc Reopened (vẫn còn lỗi). Mỗi công ty có thể đặt tên khác nhau nhưng flow cơ bản là vậy."
Tip: Vẽ nhanh lên tay hoặc xin tờ giấy mô tả luồng. HR sẽ thấy bạn tư duy có hệ thống.
Câu 3: Phân biệt QA và QC?
HR muốn gì: Nhiều fresher nhầm hai khái niệm này.
Đáp án mẫu tốt: "QA - Quality Assurance (đảm bảo chất lượng) - là quá trình, tập trung ngăn lỗi xảy ra ngay từ đầu, như review yêu cầu, quy trình làm việc. QC - Quality Control (kiểm soát chất lượng) - là sản phẩm, tập trung tìm lỗi sau khi có sản phẩm. Tester thực tế thường làm cả hai, nhưng chủ yếu nghiêng về QC hơn."
Câu 4: Phân biệt Functional testing và Non-functional testing?
Đáp án mẫu tốt: "Functional testing (kiểm thử chức năng) kiểm tra phần mềm làm đúng chức năng không - ví dụ nút đăng nhập có hoạt động không. Non-functional testing kiểm tra các yếu tố như tốc độ (performance testing), bảo mật (security testing), giao diện (UI testing). Fresher thường bắt đầu với functional testing trước."
Câu 5: Test case là gì? Cấu trúc một test case gồm những gì?
Đáp án mẫu tốt: "Test case là kịch bản kiểm thử - mô tả bước test cụ thể và kết quả mong đợi. Cấu trúc gồm: Test case ID, tiêu đề, điều kiện tiên quyết (precondition), các bước thực hiện (steps), kết quả mong đợi (expected result), kết quả thực tế (actual result), và trạng thái Pass/Fail."
Lỗi cần tránh: Chỉ nói "test case là bộ các bước test". Thiếu phần expected result - quan trọng nhất.
Câu 6: Phân biệt Smoke testing, Sanity testing, và Regression testing?
Ba loại này hay bị nhầm lẫn. Cách nhớ đơn giản:
- Smoke testing = bật điện thoại xem có sáng không. Test nhanh các tính năng quan trọng nhất trước khi test sâu hơn. Làm khi nhận build mới từ dev.
- Sanity testing = sau khi dev fix bug, test nhanh đúng phần đó để xác nhận fix đúng. Hẹp hơn smoke.
- Kiểm thử hồi quy (regression testing) = sau thay đổi, test lại toàn bộ tính năng cũ để đảm bảo không hỏng. Rộng nhất, tốn thời gian nhất.
Mình từng skip regression vì nghĩ "chỉ fix 1 dòng code nhỏ". Kết quả là tính năng giỏ hàng bị ảnh hưởng, phải fix lại từ đầu. Từ đó không bao giờ bỏ bước này nữa.
Nhóm 2: Câu hỏi kỹ năng thực hành
HR muốn biết bạn không chỉ học lý thuyết. Nhóm câu hỏi này đánh giá bạn có thực sự làm được không.
Câu 7: Viết test case cho chức năng đăng nhập (login)?
Đây là câu hỏi thực hành kinh điển nhất. Gần như 100% công ty hỏi câu này.
Lỗi phổ biến: Chỉ viết 2-3 test case "đúng username/pass" và "sai username/pass" rồi dừng. Như vậy HR biết ngay bạn chưa test đủ.
Đáp án tốt - phải cover ít nhất 3 nhóm:
Happy path (luồng đúng):
- Đăng nhập đúng username và password → vào được trang chủ
Invalid input (nhập sai):
- Sai password → thông báo lỗi rõ ràng
- Sai username → thông báo lỗi
- Để trống cả hai trường → validate ngay
- Để trống chỉ password → validate đúng trường
- Password sai quá 5 lần → khóa tài khoản (nếu có tính năng này)
Edge case (trường hợp biên):
- Password có ký tự đặc biệt (!@#$%) → vẫn login được
- Username/password có dấu cách ở đầu/cuối → trim hay không?
- Độ dài tối đa của trường input
- SQL injection cơ bản: nhập
' OR 1=1 --vào ô username
Edge case là nơi ẩn bug nghiêm trọng nhất - đừng bỏ qua
Tips khi trả lời: Nói "Mình sẽ chia thành 3 nhóm: happy path, invalid input, và edge case". HR sẽ thấy bạn có tư duy có hệ thống.
Câu 8: Làm thế nào để viết bug report tốt?
Đáp án mẫu tốt: "Bug report tốt phải đủ để dev reproduce được - tức làm lại đúng lỗi đó. Gồm: tiêu đề rõ ràng mô tả vấn đề, môi trường test (device, OS, browser, version), các bước reproduce chi tiết từng bước, expected result là kết quả đúng phải có, actual result là kết quả thực tế bị sai, severity (mức độ nghiêm trọng), và screenshot/video đính kèm."
Tại sao cần kỹ: Bug report thiếu thông tin = dev không reproduce được = bug không được fix = mình phải làm lại. Test case không kỹ = người khác không đọc hiểu = mất thời gian cả team.
Câu 9: Bạn đã dùng tool nào để quản lý bug?
Fresher thường lo vì chưa có kinh nghiệm thực tế. Nhưng câu này không cần kinh nghiệm đi làm mới trả lời được.
Đáp án mẫu: "Mình có tìm hiểu và thử qua Jira và Trello để quản lý task và bug. Jira phổ biến ở nhiều công ty nên mình đã đọc tài liệu cơ bản và thực hành trên bản free. Nếu công ty dùng tool khác, mình sẵn sàng học."
Thêm điểm cộng nếu đề cập TestRail (tool viết test case), hay nói đã thực hành với Postman cho API testing.
Câu 10: Bạn biết gì về API testing?
Đáp án mẫu cho fresher: "API testing là kiểm thử trực tiếp lớp logic của ứng dụng, không qua giao diện. Mình biết dùng Postman để gửi request và kiểm tra response - ví dụ gửi POST request đăng nhập và xem status code có trả về 200 không, body có đúng format JSON không. Mình hiểu các HTTP methods cơ bản: GET, POST, PUT, DELETE."
Nếu chưa biết Postman: Thành thật là chưa dùng nhưng đã tìm hiểu và sẽ thực hành. Đừng nói "không biết" rồi dừng.
Câu 11: Tester cần biết code không?
Đáp án: "Manual tester không bắt buộc phải biết code. Nhưng biết cơ bản HTML, SQL để query database kiểm tra dữ liệu sẽ là lợi thế lớn. Về lâu dài, nếu muốn làm automation testing thì cần học code - thường là Python hoặc Java."
Trấn an cho người chưa biết code: Không cần biết code để bắt đầu. Logic và tỉ mỉ quan trọng hơn nhiều ở giai đoạn đầu.
Câu 12: Bạn sẽ kiểm tra tính năng nào trước khi có nhiều tính năng cần test?
HR muốn gì: Đánh giá cách bạn prioritize - một kỹ năng quan trọng.
Đáp án mẫu: "Mình sẽ ưu tiên theo: 1) Tính năng core - ảnh hưởng trực tiếp đến luồng chính của user, ví dụ đăng nhập, thanh toán. 2) Tính năng mới được dev vừa bàn giao. 3) Tính năng bị bug nhiều lần trước. 4) Tính năng ít người test. Ngoài ra sẽ confirm với PM/lead để chắc chắn ưu tiên đúng."
Nhóm 3: Câu hỏi tư duy và xử lý tình huống
Đây là nhóm câu hỏi HR dùng để phân biệt fresher hiểu nghề với fresher chỉ học thuộc lòng.
Tư duy có hệ thống - điểm khác biệt quan trọng nhất khi phỏng vấn
Câu 13: Bạn tìm ra bug quan trọng nhưng deadline sắp hết - bạn xử lý thế nào?
HR muốn gì: Cách bạn cân bằng giữa quality và deadline - không có đáp án tuyệt đối.
Đáp án mẫu: "Mình sẽ không tự quyết định bỏ qua hay delay. Bước đầu tiên là đánh giá severity của bug - nghiêm trọng đến mức nào, ảnh hưởng bao nhiêu user. Sau đó report ngay cho lead/PM với thông tin đủ để họ quyết định: delay release, fix nhanh, hay accept risk. Tester không phải người quyết định release, nhưng phải đảm bảo thông tin đủ và kịp thời."
Lỗi cần tránh: Nói "mình sẽ bỏ qua bug nhỏ để kịp deadline" hoặc "mình sẽ từ chối release". Cả hai đều thể hiện thiếu hiểu biết về vai trò tester.
Câu 14: Dev nói "đây không phải bug, đây là feature" - bạn phản ứng thế nào?
Đây là tình huống có thật và xảy ra thường xuyên.
Đáp án mẫu: "Mình sẽ kiểm tra lại requirement - tài liệu yêu cầu ban đầu. Nếu requirement không đề cập rõ, mình sẽ hỏi PM/BA để clarify. Nếu behavior hiện tại khác với requirement đã viết, đó là bug. Nếu requirement chưa rõ và dev implement theo một cách hợp lý, mình sẽ đề xuất update requirement. Không tranh cãi với dev dựa trên cảm tính."
Câu 15: Bạn sẽ làm gì nếu không có tài liệu yêu cầu (requirement)?
Đáp án mẫu: "Tình huống này thực tế hay gặp ở startup. Mình sẽ: test dựa trên UX logic thông thường, so sánh với các ứng dụng tương tự, hỏi trực tiếp dev và PM để hiểu intent, và đặc biệt chú ý đến edge case vì không có spec rõ là lúc dễ bỏ lọt nhất."
Câu 16: Mô tả quy trình test của bạn khi nhận một tính năng mới?
Đáp án mẫu: "Mình sẽ đi theo flow: 1) Đọc kỹ requirement và hỏi nếu chưa rõ. 2) Phân tích và viết test case, chia các nhóm happy path - invalid - edge case. 3) Review test case với lead nếu có. 4) Thực hiện test, ghi chép kết quả. 5) Log bug với đủ thông tin. 6) Sau khi dev fix, retest và regression testing phần liên quan. 7) Sign off nếu pass."
Câu 17: Bạn hiểu SDLC và vị trí của tester trong đó thế nào?
SDLC - Software Development Life Cycle (vòng đời phát triển phần mềm) gồm các giai đoạn: Planning → Requirements → Design → Development → Testing → Deployment → Maintenance.
Đáp án mẫu: "Tester tham gia từ giai đoạn Requirements - đọc và review spec để phát hiện mâu thuẫn sớm. Tham gia nhiều nhất ở giai đoạn Testing. Nhưng ở nhiều team theo Agile, tester làm việc song song với dev, không chờ dev xong mới test."
Câu 18: Bạn biết gì về Agile/Scrum?
Đáp án mẫu cho fresher: "Agile là phương pháp phát triển phần mềm linh hoạt, làm việc theo sprint - chu kỳ ngắn thường 2 tuần. Scrum là một framework trong Agile. Tester trong Scrum tham gia daily standup, test trong cùng sprint với dev, và đảm bảo done criteria của user story. Mình đã đọc về Scrum và hiểu cơ bản các ceremony: sprint planning, daily standup, sprint review, retrospective."
Nhóm 4: Câu hỏi cá nhân - và câu hỏi nhạy cảm nhất
Đây là nhóm nhiều bạn chuẩn bị kỹ kiến thức kỹ thuật nhưng lại không chuẩn bị. HR hỏi để đánh giá động lực thật sự và khả năng gắn bó.
Câu 19: Tại sao bạn muốn trở thành tester?
Đáp án yếu (rất nhiều bạn nói): "Vì tester dễ vào nghề IT." Câu này không sai, nhưng không gây ấn tượng gì.
Đáp án mạnh hơn: Kết nối với tính cách hoặc kinh nghiệm thật của bạn. Ví dụ: "Mình nhận ra mình hay để ý những điều người khác bỏ qua - kiểm tra lại trước khi submit, đọc kỹ trước khi ký. Khi tìm hiểu về tester, mình thấy đây là nghề phù hợp với cách mình suy nghĩ. Tìm ra lỗi trước khi người dùng gặp phải - có gì thú vị hơn."
Câu 20: Điểm mạnh và điểm yếu của bạn liên quan đến testing?
Tip: Điểm yếu phải thật - nhưng kèm hành động cải thiện.
Đáp án mẫu: "Điểm mạnh: mình tỉ mỉ và kiên nhẫn - có thể test cùng một flow nhiều lần mà không bỏ sót. Điểm yếu: mình đôi khi mất nhiều thời gian vì muốn test thật kỹ. Mình đang cải thiện bằng cách học cách prioritize test case theo risk - test case nào quan trọng nhất test trước."
Lỗi cần tránh: Nói điểm yếu là "mình quá cẩn thận" hay "mình làm việc quá chăm chỉ" - HR đã nghe câu này nhiều lần.
Câu 21: Tại sao bạn chọn công ty chúng tôi?
Phải chuẩn bị riêng cho từng công ty. Tối thiểu biết: công ty làm sản phẩm gì, domain gì, quy mô ra sao.
Đáp án mẫu: "Mình biết công ty đang xây dựng [tên sản phẩm/domain]. Mình thấy thú vị vì [lý do cụ thể]. Ngoài ra mình đọc review trên ITviec và thấy nhiều người đánh giá team tech ở đây học hỏi được nhiều - đó là điều mình đang tìm kiếm ở công ty đầu tiên."
Chuẩn bị thông tin công ty trước khi phỏng vấn - điểm cộng lớn
Câu 22: Bạn có câu hỏi gì cho chúng tôi không?
Đừng nói "không có". Đây là cơ hội thể hiện bạn nghiêm túc.
Câu hỏi tốt: "Team test hiện tại có bao nhiêu người và tester sẽ phối hợp với dev như thế nào?" hoặc "Fresher ở công ty thường mất bao lâu để tự chạy được một sprint độc lập?"
Cách trả lời "Tại sao bạn chuyển từ ngành X sang tester?"
Đây là câu hỏi nhiều bạn sợ nhất. Mình hiểu cảm giác đó - như thể phải "biện hộ" cho quyết định của mình.
Thực ra HR không hỏi để phán xét. Họ muốn biết: bạn có hiểu mình đang làm gì không, và bạn có khả năng gắn bó không.
Chuyển ngành không phải điểm yếu - đó là câu chuyện của bạn
Công thức trả lời: 3 phần
Phần 1: Thừa nhận - không phủ nhận ngành cũ
Đừng nói "ngành cũ không có tương lai" hay "lương thấp". HR sẽ lo bạn cũng rời tester vì lý do tương tự sau này.
Thay vào đó: "Mình đã làm [ngành X] và học được nhiều - đặc biệt là [kỹ năng cụ thể]."
Phần 2: Cầu nối - kỹ năng ngành cũ giúp ích cho tester thế nào
Đây là phần quan trọng nhất. Mỗi ngành đều có kỹ năng chuyển được:
- Kế toán/Tài chính: Quen với con số, tỉ mỉ kiểm tra số liệu → test data validation tốt
- Giáo viên/Đào tạo: Quen viết tài liệu, giải thích rõ ràng → bug report và test case rõ ràng hơn
- Bán hàng/Customer Service: Hiểu user journey, biết user thật sự làm gì → test UX tốt hơn
- Logistics/Vận hành: Quen với quy trình, checklist → tư duy test case có hệ thống
- Y tế/Điều dưỡng: Quen với quy trình nghiêm ngặt, không được phép sai → mindset quality tốt
Phần 3: Định hướng - tại sao tester, tại sao bây giờ
"Mình tìm hiểu về tester trong [thời gian] và nhận ra [điều cụ thể]. Mình đã [hành động cụ thể: học khóa học, làm project thử, đọc tài liệu] để chuẩn bị."
Ví dụ đáp án cụ thể theo ngành cũ
Từ kế toán: "Mình làm kế toán 3 năm và học được tính tỉ mỉ - kiểm tra số liệu không được phép sai một con số. Khi tìm hiểu về testing, mình thấy mindset này rất phù hợp: test không được bỏ sót một case. Mình đã tự học test cơ bản 3 tháng và làm thử test case cho ứng dụng quản lý chi phí cá nhân để thực hành."
Từ customer service: "Mình làm CS 2 năm, ngày nào cũng nghe user complain về app lỗi. Lúc đó mình mới nhận ra: nếu tester làm tốt hơn, user không phải chịu đựng những lỗi đó. Đó là lúc mình quyết định học testing - muốn fix vấn đề từ gốc thay vì xin lỗi user."
Từ giáo viên: "Mình dạy học 4 năm và quen với việc phân tích - học sinh không hiểu bài là do bước nào? Khi học testing, mình thấy mindset phân tích nguyên nhân-hậu quả này rất ứng dụng. Mình đã tự học và thực hành viết test case trong 2 tháng qua."
Điều HR thực sự muốn nghe
- Bạn có suy nghĩ rõ ràng về quyết định, không bốc đồng
- Bạn đã chuẩn bị cụ thể, không chỉ "muốn thử"
- Kỹ năng từ ngành cũ là lợi thế, không phải gánh nặng
- Bạn hiểu tester là gì và có thể gắn bó
Thấy áp lực với câu hỏi này là bình thường. Mình đã coaching nhiều bạn chuyển ngành, và hầu hết lo lắng thái quá. Nếu bạn đã tự học 1-3 tháng và có project thực hành dù nhỏ, HR sẽ thấy sự nghiêm túc ngay.