Trả Lời Phỏng Vấn Fresher Tester



- Vì sao bài viết này dành cho bạn?
- Nguyên tắc chung trước khi vào từng câu hỏi
- Câu hỏi 1: Kiểm thử phần mềm là gì?
- Câu hỏi 2: Phân biệt verification và validation
- Câu hỏi 3: Hãy test chức năng đăng nhập
- Câu hỏi 4: Bug quan trọng hay test case quan trọng hơn?
- Câu hỏi 5: Bạn sẽ học gì trong 6 tháng đầu làm tester?
- Tổng kết
- Bình luận
Vì sao bài viết này dành cho bạn?
Nếu bạn là sinh viên sắp ra trường, fresher mới đi làm hoặc người chuyển ngành đang chuẩn bị phỏng vấn vị trí tester, bài viết này tổng hợp cách trả lời các câu hỏi phỏng vấn phổ biến nhất ở cấp độ entry-level, kèm mẫu câu trả lời thật và cách người phỏng vấn đánh giá từng câu trả lời. Bạn không cần kinh nghiệm làm dự án thật; các ví dụ trong bài đều lấy từ tình huống đơn giản mà ai cũng có thể tự tập luyện.
Các câu hỏi phỏng vấn manual testing cho người mới bắt đầu thường xoay quanh một nhóm cố định: khái niệm kiểm thử, quy trình phát triển, cách thiết kế test case và các câu hỏi tình huống, đúng như danh mục câu hỏi phỏng vấn phổ biến được tổng hợp trên GeeksforGeeks. Điều quan trọng hơn việc thuộc lòng câu trả lời là biết người phỏng vấn muốn nghe điều gì đằng sau mỗi câu hỏi.
Khi phỏng vấn fresher vị trí tester, nhà tuyển dụng đánh giá cao điều gì nhất?
Chọn một đáp án
Nguyên tắc chung trước khi vào từng câu hỏi
Người phỏng vấn fresher không kỳ vọng bạn có kinh nghiệm dự án thật. Họ kỳ vọng ba điều: bạn hiểu khái niệm theo cách của riêng mình thay vì đọc thuộc, bạn có tư duy phân tích thể hiện qua ví dụ, và bạn trung thực về điều mình chưa biết. Một câu trả lời có ví dụ cụ thể luôn thắng một câu trả lời liệt kê định nghĩa, vì ví dụ chứng tỏ bạn đã thực sự xử lý tình huống chứ không chỉ đọc lý thuyết.
Khi gặp câu hỏi chưa biết, cách trả lời an toàn và ấn tượng là thừa nhận giới hạn kèm hướng suy nghĩ của bạn: "Phần này em chưa từng làm, nhưng theo cách em hiểu thì...". Câu trả lời này vừa trung thực, vừa cho thấy bạn có khả năng tự suy luận, một phẩm chất quan trọng của nghề kiểm thử.
Câu hỏi 1: Kiểm thử phần mềm là gì?
Câu hỏi mở màn phổ biến nhất, và cũng là nơi nhiều ứng viên trả lời theo kiểu đọc từ điển. Người phỏng vấn không cần định nghĩa chuẩn; họ cần xem bạn có thể diễn đạt bằng ngôn ngữ tự nhiên và gắn với mục đích thật hay không.
Mẫu trả lời: "Theo cách em hiểu, kiểm thử phần mềm là quá trình dùng sản phẩm theo nhiều cách khác nhau để phát hiện hành vi sai so với yêu cầu, trước khi sản phẩm đến tay người dùng. Mục đích cuối cùng không phải là tìm lỗi cho vui, mà là giảm rủi ro: rủi ro người dùng mất tiền, mất dữ liệu hoặc mất niềm tin vào sản phẩm."
Điểm cộng trong câu trả lời này là phần "mục đích cuối cùng": nó cho thấy bạn hiểu kiểm thử phục vụ kinh doanh, không chỉ là công việc kỹ thuật. Điểm trừ thường gặp là ứng viên chỉ trả lời "là tìm bug trong phần mềm", một định nghĩa đúng nhưng quá hẹp và thiếu chiều sâu.
Câu hỏi 2: Phân biệt verification và validation
Đây là câu hỏi kinh điển tách ứng viên nào học thật sự với ứng viên chỉ đọc lướt. Verification là kiểm tra "chúng ta có đang xây đúng cách không", tức là rà từng artifact của quy trình như requirement, tài liệu thiết kế. Validation là kiểm tra "chúng ta có xây đúng cái cần xây không", tức là thử sản phẩm thật xem có đáp ứng nhu cầu user hay không.
| Tiêu chí | Verification | Validation |
|---|---|---|
| Câu hỏi cốt lõi | Xây đúng cách không? | Xây đúng thứ cần xây không? |
| Thời điểm | Xuyên suốt quy trình, trước khi có sản phẩm chạy được | Khi đã có sản phẩm chạy được |
| Ví dụ | Review requirement, review tài liệu thiết kế, review test case | Chạy UAT, exploratory testing trên bản build thật |
| Người làm | Cả team: BA, developer, tester | Tester, PO và cả user thật |
Mẹo ghi nhớ: verification kiểm tra paper (tài liệu), validation kiểm tra product (sản phẩm). Khi trả lời, hãy kèm một ví dụ thật từ dự án hoặc bài tập của bạn, chẳng hạn: "Khi làm bài tập nhóm, việc tụi em ngồi đọc lại đề bài xem có hiểu đúng yêu cầu không chính là verification, còn lúc chạy thử tính năng trên máy xem có ra kết quả như người dùng cần không là validation."
Câu hỏi 3: Hãy test chức năng đăng nhập
Câu hỏi tình huống phổ biến nhất trong phỏng vấn tester, và cũng là câu hỏi mà nhiều ứng viên tự làm khó mình bằng cách liệt kê case theo kiểu máy móc. Bài viết Em Sẽ Test Form Login Này Thế Nào? phân tích chi tiết cách biến câu hỏi này thành cơ hội thể hiện tư duy, nhưng ở mức phỏng vấn fresher, cấu trúc trả lời đủ tốt gồm ba lớp.
Lớp một, xác nhận yêu cầu trước khi trả lời: hỏi ngược người phỏng vấn "cho em xác nhận, đây là đăng nhập bằng email và mật khẩu đúng không, có yêu cầu về bảo mật hay rate limit gì không". Chỉ việc hỏi ngược này đã ghi điểm, vì nó thể hiện thói quen làm rõ yêu cầu thay vì vội vã. Lớp hai, trình bày theo nhóm: functional (đúng sai thông tin, quên mật khẩu), security cơ bản (bấm nhanh nhiều lần, session), UI và thông báo lỗi. Lớp ba, nêu ưu tiên: "Nếu chỉ được chọn một nhóm, em sẽ tập trung vào negative case và xử lý lỗi, vì đó là nơi bug nghiêm trọng hay trốn nhất."
Công thức trả lời khi chưa biết:
- Thừa nhận thẳng: "Phần này em chưa từng làm trong dự án thật."
- Đưa ra cách hiểu hiện tại: "Nhưng theo em hiểu thì..."
- Nói hướng bạn sẽ tìm hiểu: "Em sẽ bắt đầu bằng việc đọc tài liệu chính thức và thử trên dự án nhỏ."
Câu hỏi 4: Bug quan trọng hay test case quan trọng hơn?
Câu hỏi bẫy phổ biến, thiết kế để xem ứng viên có bị sa đà vào tranh luận đúng sai tuyệt đối hay biết nhìn hai mặt. Câu trả lời tốt không chọn phe, mà giải thích quan hệ giữa hai thứ.
Mẫu trả lời: "Em nghĩ hai thứ phục vụ mục đích khác nhau nên không thể so hơn kém trực tiếp. Test case là kế hoạch: nó đảm bảo việc kiểm thử có hệ thống, không bỏ sót và người khác lặp lại được. Bug là kết quả có giá trị thật: một bug nghiêm trọng được tìm đúng lúc có thể cứu cả một release. Nhưng nếu chỉ chạy theo số bug mà không có test case, em không chứng minh được mình đã test những gì, và khi có sự cố thì không truy ngược lại được. Trong thực tế, em sẽ dùng test case làm nền và luôn báo bug kèm đầy đủ thông tin để nó có giá trị cho developer."
Câu trả lời này đạt điểm vì không né câu hỏi, có quan điểm rõ ràng ("không so hơn kém trực tiếp") và kết bằng cách áp dụng vào chính công việc của ứng viên.
Câu hỏi 5: Bạn sẽ học gì trong 6 tháng đầu làm tester?
Câu hỏi về lộ trình học cho thấy nhà tuyển dụng muốn biết bạn có bền bỉ không. Câu trả lời nên có mốc cụ thể thay vì chung chung "em sẽ cố gắng học hỏi".
Mẫu trả lời theo mốc: "Trong tháng đầu, em sẽ tập trung hiểu nghiệp vụ sản phẩm và workflow quản lý bug của team, vì không hiểu nghiệp vụ thì viết test case nào cũng hời hợt. Từ tháng hai đến tháng tư, em sẽ củng cố kỹ năng viết test case và bug report theo chuẩn của team, đồng thời học SQL cơ bản để tự kiểm chứng dữ liệu thay vì chỉ tin vào màn hình, ví dụ theo lộ trình của khóa SQL dành cho QA engineer. Từ tháng năm, em sẽ bắt đầu học API testing cơ bản, vì hiểu API giúp em test sâu hơn lớp giao diện, như khóa API Testing cơ bản. Mục tiêu của em sau sáu tháng là không cần senior nhắc lại lỗi cũ."
Điểm cộng là mỗi giai đoạn có mục tiêu đo được và liên kết với hoạt động thật của team. Bạn có thể điều chỉnh thứ tự kỹ năng theo yêu cầu công việc trong JD của vị trí mình ứng tuyển, vì cách làm này chứng tỏ bạn đã đọc kỹ mô tả công việc. Nếu bạn chưa có bất kỳ kinh nghiệm thực hành nào, bài 7 ngày thử nghề Tester là một cách hiệu quả để có chất liệu nói trong phỏng vấn, còn bài Lộ Trình Học Tester: Từ Zero Đến Chuyên Nghiệp giúp bạn trình bày lộ trình dài hạn một cách thuyết phục.
Bốn việc nên làm trước buổi phỏng vấn tester
Chuẩn bị trước hai buổi phỏng vấn sẽ hiệu quả hơn ôn gấp trong một đêm.
Tự phỏng vấn form login
Luyện trả lời câu "test form đăng nhập thế nào" bằng giọng nói thật, ghi âm và nghe lại, sửa chỗ vấp.
Chuẩn bị một ví dụ thật
Tìm một ứng dụng bạn hay dùng, tự viết 10 test case và một bug report giả định để kể trong phỏng vấn.
Đọc kỹ JD và note 3 kỹ năng
Từ mô tả công việc, chọn ba kỹ năng team cần và chuẩn bị ví dụ cho từng kỹ năng, dù là từ bài tập.
Chuẩn bị 2 câu hỏi ngược
Ví dụ "team đang dùng quy trình nào để quản lý bug" hoặc "kỳ vọng gì cho fresher trong 3 tháng đầu".
Tổng kết
Phỏng vấn tester cho fresher không đo số câu trả lời đúng, mà đo tư duy: bạn có phân tích bài toán như một tester hay chỉ nhắc lại lý thuyết. Nắm chắc nhóm câu hỏi khái niệm (kiểm thử là gì, verification và validation), nhóm tình huống (test một chức năng cụ thể) và nhóm thái độ (lộ trình học, cách xử lý điều chưa biết), rồi luyện trả lời bằng ví dụ thật, dù ví dụ đó chỉ đến từ bài tập tự làm.
- Trả lời bằng ngôn ngữ của bạn kèm ví dụ, không đọc thuộc định nghĩa.
- Với câu hỏi tình huống: hỏi ngược để làm rõ, trình bày theo nhóm, nêu ưu tiên.
- "Em chưa biết" kèm hướng suy nghĩ luôn tốt hơn trả lời vòng vo.
- Lộ trình học có mốc cụ thể thể hiện sự bền bỉ tốt hơn mọi lời hứa chung chung.
Nếu bạn đang chuẩn bị cho buổi phỏng vấn tester đầu tiên, hãy thử trả lời thành tiếng câu "hãy test form đăng nhập" ngay sau khi đọc xong bài này, rồi so sánh với cấu trúc ba lớp ở trên. Điều bạn thấy thiếu trong câu trả lời của mình chính là thứ cần luyện trước khi đến buổi phỏng vấn thật.
Bình luận (0)