Bài viết này phân tích chi tiết sáu thành phần thường gặp trong một buổi phỏng vấn Manual Tester. Ở mỗi phần, chúng ta sẽ cùng làm rõ ba điều: nhà tuyển dụng thường hỏi gì, họ thực sự đánh giá điều gì, và bạn nên làm gì để ghi điểm.

Tổng quan: sáu thành phần của một buổi phỏng vấn

Một buổi phỏng vấn QC điển hình thường diễn ra theo trình tự từ làm quen, qua kiến thức và kỹ năng chuyên môn, rồi khép lại bằng tình huống và hỏi đáp hai chiều:

  1. Giới thiệu và phá băng — màn chào hỏi, làm quen.
  2. Kiến thức nền tảng — hiểu biết về nghề và lý thuyết kiểm thử.
  3. Kỹ thuật thiết kế test case — năng lực chuyên môn cốt lõi.
  4. Quy trình và cấp độ kiểm thử — bức tranh tổng thể của hoạt động test.
  5. Công cụ và thực hành — kỹ năng thực tế.
  6. Tình huống và câu hỏi ngược — tư duy xử lý và thái độ.

Một lưu ý quan trọng: với fresher, nhà tuyển dụng thường nhấn mạnh ba phần đầu (thái độ, kiến thức nền, kỹ thuật cơ bản); còn với junior, các phần về kinh nghiệm thực tế, công cụ và xử lý tình huống sẽ được khai thác sâu hơn.

 

1. Giới thiệu và phá băng

Phần mở đầu tưởng nhẹ nhàng nhưng lại quyết định ấn tượng đầu tiên của bạn trong mắt nhà tuyển dụng.

Những câu hỏi thường gặp

  • Em hãy giới thiệu đôi nét về bản thân.
  • Vì sao em chọn nghề kiểm thử phần mềm?
  • Em định hướng phát triển theo manual, automation hay cả hai?
  • Em biết gì về công ty và sản phẩm của chúng tôi?
  • Mục tiêu nghề nghiệp của em trong một đến hai năm tới là gì?

Nhà tuyển dụng đánh giá điều gì

Ở phần này, điều được quan tâm không hẳn là thành tích, mà là thái độ, sự tự tin và khả năng trình bày mạch lạc. Họ muốn xem bạn có thực sự nghiêm túc với nghề testing hay chỉ chọn vì "dễ xin việc", và liệu định hướng của bạn có phù hợp với vị trí đang tuyển hay không.

Mẹo ghi điểm

  • Trả lời theo cấu trúc Hiện tại – Quá khứ – Tương lai: bạn đang là ai, đã học/làm gì liên quan, và muốn phát triển ra sao.
  • Giữ ngắn gọn trong một đến hai phút, đúng trọng tâm, không kể lể dài dòng.
  • Tìm hiểu trước về công ty để trả lời tự nhiên câu "vì sao ứng tuyển".
  • Với fresher, hãy thể hiện rõ tinh thần ham học hỏi — đây là yếu tố thường được đánh giá cao hơn cả bảng điểm.

2. Kiến thức nền tảng

Đây là phần kiểm tra xem bạn có hiểu đúng bản chất công việc của một kiểm thử viên hay không.

Những câu hỏi thường gặp

  • Công việc thực sự của một kiểm thử viên là gì?
  • Mục đích của kiểm thử phần mềm là gì — có phải chỉ để tìm bug?
  • Em hãy kể bảy nguyên tắc kiểm thử phần mềm.
  • SDLC (vòng đời phát triển phần mềm) và STLC (vòng đời kiểm thử) gồm những giai đoạn nào?
  • Phân biệt Error, Defect và Failure.

Nhà tuyển dụng đánh giá điều gì

Họ muốn biết bạn nắm nền tảng lý thuyết đến đâu và có hiểu vai trò thật sự của tester trong dự án không. Một quan niệm sai phổ biến cần tránh là nghĩ rằng "tester chỉ đi tìm bug" — trên thực tế, vai trò của kiểm thử viên là góp phần đảm bảo chất lượng sản phẩm, trong đó tìm lỗi chỉ là một phần.

Mẹo ghi điểm

  • Hiểu bản chất, không học vẹt: nắm được ý nghĩa của từng nguyên tắc thay vì đọc thuộc lòng.
  • Luôn kèm ví dụ thực tế khi giải thích một khái niệm.
  • Nắm chắc bảy nguyên tắc kiểm thử vì đây là nội dung rất hay bị hỏi sâu.
  • Biết vị trí của hoạt động test trong SDLC/STLC để cho thấy bạn hiểu bức tranh tổng thể.

3. Kỹ thuật thiết kế test case

Nếu phần kiến thức nền tảng kiểm tra "bạn hiểu gì", thì phần này kiểm tra "bạn làm được gì". Đây là phần chuyên môn cốt lõi của một tester.

Những câu hỏi thường gặp

  • Có một ô nhập tuổi nhận giá trị từ 1 đến 100, em sẽ test thế nào?
  • Equivalence Partitioning và Boundary Value Analysis là gì?
  • Khi nào nên dùng Decision Table, khi nào dùng State Transition?
  • Một test case đầy đủ gồm những trường thông tin nào?
  • Một bug report tốt cần đạt những tiêu chí gì?

Nhà tuyển dụng đánh giá điều gì

Họ muốn xem bạn có tư duy thiết kế test case có hệ thống hay chỉ test theo cảm tính. Khả năng chọn đúng kỹ thuật cho từng loại đầu vào, và viết được test case lẫn bug report rõ ràng, chính là thước đo năng lực thực sự ở phần này.

Các kỹ thuật cần nắm vững

  • Equivalence Partitioning (phân vùng tương đương): chia dữ liệu thành các nhóm có hành vi giống nhau để giảm số lượng test case.
  • Boundary Value Analysis (phân tích giá trị biên): tập trung kiểm tra tại các giá trị biên, nơi lỗi hay xuất hiện nhất.
  • Decision Table: dùng khi có nhiều điều kiện kết hợp logic với nhau.
  • State Transition: dùng khi hệ thống có các trạng thái chuyển đổi (ví dụ: đăng nhập sai ba lần thì khóa tài khoản).

Mẹo ghi điểm

  • Chọn đúng kỹ thuật theo loại dữ liệu đầu vào — EP và BVA thường đi cùng nhau.
  • Mỗi test case chỉ kiểm tra một mục tiêu rõ ràng, tránh gộp nhiều mục đích.
  • Bug report phải tái hiện được: ghi rõ các bước, kết quả mong đợi và kết quả thực tế, kèm ảnh chụp/video.
  • Luôn minh họa bằng ví dụ cụ thể khi được hỏi về một kỹ thuật.

4. Quy trình và cấp độ kiểm thử

Phần này đánh giá mức độ am hiểu của bạn về bức tranh tổng thể của hoạt động kiểm thử trong một dự án.

Những câu hỏi thường gặp

  • Em phân biệt smoke test với sanity test không?
  • Bốn cấp độ kiểm thử là gì và ai thực hiện mỗi cấp độ?
  • Functional testing và Non-functional testing khác nhau ra sao?
  • Regression testing là gì, khi nào cần chạy?
  • Vòng đời của một lỗi (Defect Life Cycle) gồm những trạng thái nào?

Các khái niệm trọng tâm

  • Bốn cấp độ kiểm thử: Unit → Integration → System → Acceptance (UAT), mỗi cấp độ có phạm vi và người thực hiện khác nhau.
  • Smoke vs Sanity: smoke test kiểm tra rộng nhưng nông để xác nhận các chức năng chính có chạy; sanity test kiểm tra hẹp nhưng sâu vào phần vừa được sửa đổi.
  • Re-test vs Regression: re-test xác nhận một lỗi cụ thể đã được sửa; regression kiểm tra xem thay đổi có làm ảnh hưởng đến phần đang chạy tốt hay không.
  • Defect Life Cycle: vòng đời của một lỗi từ lúc được phát hiện (New) đến khi đóng (Closed), đi qua các trạng thái như Assigned, Open, Fixed, Retest, Reopen…

Mẹo ghi điểm

  • Nhớ thứ tự bốn cấp độ test và ai thực hiện từng cấp.
  • Phân biệt rõ smoke và sanity vì đây là câu rất hay được hỏi.
  • Hiểu khi nào chạy regression (sau mỗi thay đổi code) và vì sao nó quan trọng.
  • Gắn mỗi khái niệm với một tình huống thực tế để câu trả lời thuyết phục hơn.

5. Công cụ và thực hành

Đến phần này, nhà tuyển dụng muốn biết bạn đã thực sự "chạm tay" vào công việc tới đâu.

Những câu hỏi thường gặp

  • Em đã dùng công cụ test hoặc quản lý bug nào chưa?
  • Em test API bằng Postman như thế nào?
  • Em có biết viết câu lệnh SQL để kiểm tra dữ liệu không?
  • Các HTTP status code (200, 400, 404, 500…) có ý nghĩa gì?
  • Em dùng DevTools của trình duyệt vào những việc gì?

Những kỹ năng nên có (ưu tiên cho manual fresher/junior)

  • Postman (test API) — trọng tâm: hiểu các HTTP method (GET, POST, PUT, DELETE), cấu trúc request/response và ý nghĩa các nhóm status code.
  • SQL cơ bản — trọng tâm: biết viết câu SELECT có điều kiện và các phép JOIN cơ bản để kiểm tra dữ liệu trong database.
  • Jira (hoặc công cụ tương đương): quản lý test case và vòng đời của một bug.
  • DevTools trình duyệt: dùng tab Console để xem lỗi, tab Network để kiểm tra request khi test web.

Mẹo ghi điểm

  • Thành thạo ít nhất một công cụ quản lý test và nói rõ bạn đã dùng nó ra sao.
  • Hiểu request/response và status code — đây là kiến thức nền cho test API.
  • Biết thu thập bằng chứng lỗi bằng cách chụp hoặc quay màn hình.
  • Trung thực về mức độ đã sử dụng: nói rõ bạn làm tới đâu thay vì phóng đại, vì nhà tuyển dụng có thể "hỏi sâu" làm lộ ra.

6. Tình huống và câu hỏi ngược

Phần cuối buổi phỏng vấn thường kiểm tra cách bạn xử lý các tình huống thực tế, kỹ năng làm việc nhóm và sự chủ động.

Những câu hỏi tình huống thường gặp

  • Em tìm thấy lỗi nhưng developer nói "đây không phải bug" thì em làm gì?
  • Sắp đến deadline mà phát hiện một bug nghiêm trọng, em xử lý thế nào?
  • Em được giao test một tính năng nhưng không có tài liệu/spec, em bắt đầu từ đâu?
  • Một bug bạn báo lại không tái hiện được trên máy của dev, em làm gì?

Cách trả lời câu hỏi tình huống

Bạn nên trả lời theo cấu trúc STAR — Situation (tình huống), Task (nhiệm vụ), Action (hành động), Result (kết quả). Một số nguyên tắc quan trọng:

  • Nêu rõ cách xử lý kèm lý do, đừng trả lời chung chung.
  • Giữ thái độ bình tĩnh, không đổ lỗi cho developer hay người khác.
  • Dựa vào tài liệu/yêu cầu để bảo vệ quan điểm khi có bất đồng.
  • Biết escalate đúng lúc khi vấn đề vượt thẩm quyền của mình.

Câu hỏi ngược nên đặt cho nhà tuyển dụng

Phỏng vấn là cuộc trao đổi hai chiều, vì vậy hãy chuẩn bị sẵn một đến hai câu hỏi ngược, chẳng hạn:

  • Quy trình làm việc và công cụ của team QC hiện tại như thế nào?
  • Một fresher mới vào sẽ được onboarding và đào tạo ra sao?
  • Lộ trình phát triển từ fresher lên junior/senior ở công ty như thế nào?
  • Công ty có hỗ trợ học chứng chỉ (như ISTQB) không?

Một câu hỏi ngược thông minh không chỉ giúp bạn hiểu rõ công việc mà còn thể hiện sự nghiêm túc và chủ động. Cuối cùng, hãy khép lại buổi phỏng vấn bằng một thái độ tích cực và lời cảm ơn chân thành.

Lời kết

Sáu thành phần trên chính là khung sườn của hầu hết các buổi phỏng vấn Manual Tester ở level fresher và junior. Hiểu rõ từng phần và những gì nhà tuyển dụng thực sự quan tâm sẽ giúp bạn chuẩn bị có chiến lược thay vì học dàn trải.

Hãy nhớ rằng ở giai đoạn đầu sự nghiệp, nhà tuyển dụng không kỳ vọng bạn biết mọi thứ — điều họ tìm kiếm là một nền tảng vững, tư duy logic, thái độ cầu tiến và khả năng học hỏi nhanh. Khi bạn nắm chắc "bản đồ" sáu phần này và luyện tập trả lời cho từng phần, sự tự tin sẽ đến một cách tự nhiên.

Chúc bạn tự tin và thành công trong buổi phỏng vấn sắp tới!

Bài viết được biên soạn bởi đội ngũ IT Learn — nền tảng đào tạo kiểm thử phần mềm. Nếu bạn muốn luyện tập sâu hơn với bộ câu hỏi phỏng vấn và các buổi mock interview, hãy theo dõi các khóa học và nội dung mới nhất của trung tâm.