Question 1

Giới thiệu về bản thân và kinh nghiệm testing của bạn. Bạn tự nhận mình là manual tester, automation tester, hay cả hai?

Accepted Answer

Background -> Testing journey -> Specialization + tỷ lệ manual/auto -> Dự án tiêu biểu. Nhà tuyển dụng dùng câu hỏi này để định vị năng lực và hướng phát triển của ứng viên ngay từ đầu buổi phỏng vấn. Ứng viên mạnh không chỉ nêu "manual" hay "automation" mà trình bày rõ tỷ lệ kết hợp hợp lý - ví dụ 60% tự động hóa cho kiểm tra hồi quy, 40% thủ công cho exploratory và UAT - kèm con số cụ thể như số trường hợp kiểm tra, tỷ lệ phủ và số lỗi phát hiện được. Điểm cộng nếu ứng viên kể về một dự án có setup framework từ đầu thay vì chỉ viết thêm script vào framework có sẵn. Nhà tuyển dụng thường hỏi tiếp: "Vì sao bạn chọn tỷ lệ đó thay vì automate nhiều hơn?"

Question 2

Khi nhận một dự án mới, bạn xây dựng test strategy và test plan như thế nào? Phân biệt hai khái niệm này.

Accepted Answer

Strategy (high-level, project-wide) vs Plan (detailed, phase-specific) -> Process -> Deliverables. Nhà tuyển dụng đánh giá khả năng phân biệt và xây dựng hai tầng tài liệu kiểm tra quan trọng mà nhiều QA hay nhầm lẫn. Ứng viên mạnh giải thích rõ: test strategy là tài liệu tổng thể cho toàn dự án - định nghĩa cách tiếp cận, các cấp độ kiểm tra và phạm vi tự động hóa - trong khi test plan chi tiết cho từng giai đoạn cụ thể với lịch trình, phân công và môi trường thực thi. Điểm cộng nếu ứng viên cho thấy họ tham gia xây dựng strategy từ đầu dự án thay vì đợi dev bàn giao mới bắt đầu - đây chính là biểu hiện của Shift-Left. Nhà tuyển dụng có thể hỏi thêm: "Bạn làm gì khi strategy cần thay đổi giữa chừng do yêu cầu dự án thay đổi?"

Question 3

Bạn đã setup automation framework từ đầu bao giờ chưa? So sánh Selenium, Cypress, và Playwright - khi nào bạn chọn cái nào?

Accepted Answer

Framework experience -> Tool comparison (criteria-based) -> Decision rationale -> Architecture. Nhà tuyển dụng đánh giá kinh nghiệm thực tế xây dựng khung tự động hóa từ đầu và khả năng lựa chọn công cụ phù hợp với bối cảnh, không chỉ biết so sánh lý thuyết. Câu trả lời tốt giải thích khi nào chọn Playwright (đa trình duyệt, trace viewer mạnh, hỗ trợ nhiều ngôn ngữ), Cypress (trải nghiệm phát triển tốt, phù hợp team chủ yếu dùng Chromium), hay Selenium (khi cần hỗ trợ trình duyệt cũ hoặc kế thừa hệ sinh thái sẵn có) - đồng thời mô tả cấu trúc framework: Page Object Model hoặc screenplay pattern, tổ chức dữ liệu kiểm thử, xử lý kiểm thử không ổn định, tích hợp CI/CD. Điểm cộng nếu ứng viên nhắc đến tài liệu hướng dẫn cho thành viên mới và chiến lược chạy kiểm thử song song. Nhà tuyển dụng thường hỏi tiếp: bạn xử lý kiểm thử không ổn định như thế nào trong CI/CD?

Question 4

Bạn test API như thế nào? Ngoài happy path, bạn kiểm tra những gì? Cho ví dụ một API endpoint và các test cases bạn sẽ viết.

Accepted Answer

Approach -> Tool choice -> Test case categories -> Real endpoint example. Nhà tuyển dụng đánh giá độ sâu trong kiểm thử API, không chỉ khả năng kiểm tra đường dẫn thành công cơ bản. Câu trả lời tốt trình bày đầy đủ các nhóm: kiểm thử giá trị biên (chuỗi quá dài, số nguyên tràn bộ nhớ, mảng rỗng), kiểm thử tiêu cực (sai định dạng, thiếu trường bắt buộc, SQL injection trong đầu vào), kiểm thử xác thực (token hết hạn, sai vai trò người dùng), tính bất biến khi gọi lặp lại, và hiệu suất so với mức thỏa thuận dịch vụ. Điểm cộng nếu ứng viên nêu được ví dụ endpoint cụ thể với danh sách đầy đủ các kịch bản kiểm thử và mô tả cách tích hợp vào CI/CD để chạy tự động. Nhà tuyển dụng thường hỏi tiếp: bạn quản lý dữ liệu kiểm thử trong môi trường API như thế nào?

Question 5

Bạn integrate automation tests vào CI/CD pipeline như thế nào? Chia sẻ pipeline thực tế bạn đã setup.

Accepted Answer

Pipeline architecture -> Test stages -> Trigger strategy -> Reporting -> Failure handling. Nhà tuyển dụng đánh giá hiểu biết thực tế về tích hợp kiểm thử tự động vào CI/CD, không chỉ biết khái niệm. Câu trả lời tốt mô tả pipeline cụ thể đã thiết lập: công cụ (GitHub Actions, GitLab CI, Jenkins), thời điểm kích hoạt (mỗi pull request hay nightly build), cách chia tầng kiểm thử (kiểm thử khói 5 phút chạy trước, kiểm thử hồi quy 30 phút chạy sau), và hành động khi kiểm thử thất bại (chặn merge, thông báo Slack, tạo ticket tự động). Điểm cộng nếu ứng viên đề cập đến chạy song song để giảm thời gian (sharding), Docker để ổn định môi trường kiểm thử, và chiến lược quản lý dữ liệu kiểm thử trong CI. Nhà tuyển dụng thường hỏi tiếp: bạn xử lý kiểm thử không ổn định gây tắc nghẽn pipeline như thế nào?

Question 6

Bạn đã từng thực hiện performance testing chưa? Phân biệt load test, stress test, spike test. Bạn dùng tool gì và đọc kết quả như thế nào?

Accepted Answer

Test type definitions -> Tool experience -> Metrics interpretation -> Real bottleneck found. Nhà tuyển dụng đánh giá khả năng phân biệt và áp dụng đúng từng loại kiểm tra hiệu năng: load test kiểm tra với số lượng người dùng dự kiến, stress test tăng dần vượt giới hạn để tìm điểm gãy, spike test mô phỏng tăng đột biến như flash sale. Ứng viên mạnh biết chọn công cụ phù hợp - k6 ngày càng được ưa chuộng vì nhẹ, viết script bằng JavaScript và tích hợp CI/CD dễ hơn JMeter - và đọc kết quả đúng cách: chú trọng P95 thay vì trung bình, vì trung bình che giấu các trường hợp ngoại lệ. Điểm cộng nếu ứng viên kể được một điểm nghẽn thực tế đã phát hiện, ví dụ N+1 query hoặc connection pool cạn kiệt khi có nhiều người dùng đồng thời. Nhà tuyển dụng có thể hỏi thêm: "Bạn đã từng đưa kết quả kiểm tra hiệu năng vào báo cáo để thuyết phục PM hoặc dev thay đổi thiết kế chưa?"

Question 7

Mô tả bug lifecycle bạn đang dùng. Khi developer reject bug của bạn với lý do 'works as designed', bạn xử lý thế nào?

Accepted Answer

Bug lifecycle stages -> Reject scenario -> Evidence-based discussion -> Escalation path. Nhà tuyển dụng đánh giá không chỉ hiểu biết về vòng đời lỗi mà còn cách ứng viên xử lý tình huống phổ biến khi dev từ chối lỗi với lý do "hoạt động đúng thiết kế". Câu trả lời tốt mô tả quy trình leo thang phù hợp: xem lại yêu cầu trước, chuẩn bị bằng chứng cụ thể (ảnh chụp, video, nhật ký, trích dẫn tài liệu), trao đổi trực tiếp với dev trước khi đưa vào bình luận, mời BA hoặc Product Owner làm rõ yêu cầu nếu cần, và chỉ leo thang lên PM khi đã thử mọi cách. Điểm cộng nếu ứng viên cho thấy biết chọn lỗi nào đáng giữ lập trường và lỗi nào có thể linh hoạt - không phải lỗi nào cũng cần đẩy đến cùng. Nhà tuyển dụng thường hỏi tiếp: bạn đã từng sai khi báo lỗi chưa và xử lý thế nào?

Question 8

Bạn hiểu Shift-Left Testing như thế nào? Chia sẻ cách bạn đã áp dụng nó trong dự án thực tế - không chỉ lý thuyết.

Accepted Answer

Concept explanation -> Practical implementation -> Before/after metrics -> Team collaboration. Nhà tuyển dụng tìm kiếm ứng viên có thể chứng minh Shift-Left Testing bằng kết quả thực tế, không chỉ hiểu khái niệm. Ứng viên giỏi mô tả cụ thể cách họ tham gia review yêu cầu từ sớm, viết trường hợp kiểm tra song song với dev dựa trên tiêu chí chấp nhận, và đóng góp vào Definition of Done của từng story - kết quả đo được là mật độ lỗi giảm rõ rệt sau khi áp dụng. Điểm cộng nếu ứng viên đề cập đến BDD và cách viết kịch bản Gherkin cùng Product Owner để làm rõ yêu cầu ngay từ giai đoạn thiết kế. Nhà tuyển dụng có thể hỏi thêm: "Bạn đã từng gặp dev phản đối QA tham gia sớm chưa và xử lý thế nào?"

Question 9

AI đang thay đổi testing như thế nào trong 2026? Bạn đã dùng tool AI nào cho testing (Testim, Mabl, Katalon AI, Copilot) và đánh giá thế nào?

Accepted Answer

AI landscape in testing -> Tool experience -> Strengths/limitations -> QA role evolution. Nhà tuyển dụng đánh giá hiểu biết thực tế về AI trong kiểm thử và quan trọng hơn là tư duy phê phán về giới hạn của nó, không chỉ biết tên công cụ. Câu trả lời tốt phân biệt rõ các tầng ứng dụng AI: tạo mã kiểm thử tự động (Copilot, Gemini), tự phục hồi bộ nhận diện phần tử khi UI thay đổi (Testim, Mabl), kiểm tra hình ảnh thông minh (Percy, Applitools), và phân tích dự đoán vùng dễ lỗi. Điểm cộng nếu ứng viên giữ quan điểm cân bằng: AI giúp tăng tốc độ và giảm công bảo trì nhưng không thay thế được tư duy kiểm thử - AI không hiểu ý định người dùng, bối cảnh kinh doanh hay biết kịch bản nào quan trọng nhất. Nhà tuyển dụng thường hỏi tiếp: bạn gặp giới hạn nào khi dùng AI để sinh kịch bản kiểm thử?

Question 10

Bạn có kinh nghiệm test mobile app không? So sánh testing native app, hybrid app, và responsive web. Bạn đã dùng Appium chưa?

Accepted Answer

Mobile testing types -> Platform-specific challenges -> Tool experience -> Device strategy. Nhà tuyển dụng đánh giá hiểu biết về sự phức tạp của kiểm thử di động và chiến lược xử lý thực tế, không chỉ biết tên công cụ. Câu trả lời tốt phân biệt rõ sự khác biệt giữa native app, hybrid app và web trên trình duyệt di động về cả thách thức lẫn công cụ phù hợp (Appium cho đa nền tảng, Detox cho React Native, XCUITest cho iOS, Espresso cho Android), đồng thời nêu chiến lược thiết bị thực tế: chọn 5-10 thiết bị ưu tiên dựa trên dữ liệu phân tích của ứng dụng thay vì cố kiểm thử mọi thiết bị. Điểm cộng nếu ứng viên đề cập đến BrowserStack hoặc Sauce Labs để có farm thiết bị và kể được lỗi đặc thù theo nền tảng từng phát hiện. Nhà tuyển dụng thường hỏi tiếp: bạn xử lý kiểm thử offline và thông báo đẩy như thế nào?

Question 11

Production vừa có bug critical - user không thể thanh toán. Bạn là QA duy nhất online lúc đó. Bạn sẽ làm gì trong 30 phút đầu?

Accepted Answer

Immediate response -> Reproduce -> Communicate -> Assist fix -> Verify -> Post-mortem. Nhà tuyển dụng đánh giá khả năng xử lý sự cố với đầu óc bình tĩnh, hành động có trình tự và ưu tiên trao đổi thông tin kịp thời trong 30 phút đầu. Câu trả lời tốt mô tả rõ từng giai đoạn: 0-5 phút tái hiện lỗi và đánh giá phạm vi ảnh hưởng; 5-10 phút leo thang ngay cho dev lead và PM kèm đánh giá tác động cụ thể (không đợi có đủ thông tin mới báo); 10-20 phút hỗ trợ điều tra bằng cách so sánh với lần triển khai gần nhất; 20-30 phút kiểm thử bản vá trên môi trường kiểm thử ngay lập tức, không bỏ qua bước này dù đang gấp. Điểm cộng nếu ứng viên đề cập đến việc viết phân tích nguyên nhân gốc và đề xuất bổ sung kiểm thử hồi quy cho luồng thanh toán sau khi sự cố được giải quyết.

Question 12

PM nói 'Chỉ còn 2 ngày, test những gì quan trọng nhất thôi'. Bạn quyết định test gì và bỏ gì? Dựa trên tiêu chí nào?

Accepted Answer

Risk-based prioritization -> Criteria (business impact, change frequency, user volume) -> Test selection -> Communication. Nhà tuyển dụng đánh giá khả năng ưu tiên dựa trên rủi ro và sự minh bạch trong giao tiếp khi bị áp lực về thời gian. Ứng viên mạnh áp dụng cách tiếp cận dựa trên rủi ro một cách có cấu trúc - ưu tiên luồng nghiệp vụ cốt lõi, vùng code thay đổi nhiều trong sprint và tính năng có lượng người dùng cao - đồng thời trao đổi rõ với PM về những gì sẽ bỏ qua và mức rủi ro đi kèm. Điểm quan trọng nhất là ứng viên phải ghi lại quyết định trong báo cáo kiểm tra - không âm thầm bỏ qua rồi báo cáo "xong". Nhà tuyển dụng có thể hỏi thêm: "Nếu PM không đồng ý với rủi ro bạn đưa ra thì sao?"

Question 13

Dự án có 2000 test cases, mỗi sprint regression mất 3 ngày manual. Bạn sẽ lên kế hoạch automation thế nào để giảm xuống còn nửa ngày?

Accepted Answer

Current state analysis -> Automation candidate selection -> Phased implementation -> ROI projection. Nhà tuyển dụng đánh giá tư duy chiến lược của ứng viên khi đối mặt với bài toán tối ưu quy trình kiểm tra hồi quy ở quy mô lớn. Ứng viên giỏi không cố tự động hóa toàn bộ 2.000 trường hợp kiểm tra mà áp dụng quy tắc 80/20 - xác định 20% trường hợp kiểm tra bao phủ 80% luồng nghiệp vụ quan trọng, lên kế hoạch theo từng giai đoạn rõ ràng và tính toán ROI cụ thể để thuyết phục các bên liên quan. Điểm cộng nếu ứng viên đề cập đến kỹ thuật chạy song song (sharding) và nhấn mạnh việc giữ lại kiểm tra thủ công cho exploratory testing - không cố tự động hóa mọi thứ. Nhà tuyển dụng có thể hỏi thêm: "Framework nào bạn chọn và vì sao?"

Question 14

Trong một ngày làm việc bình thường, bạn sử dụng những tool nào? Walk me through workflow sáng đến chiều.

Accepted Answer

Daily workflow -> Tool per activity -> Integration between tools -> Efficiency tips. Nhà tuyển dụng dùng câu hỏi này để đánh giá mức độ thành thạo công cụ thực tế và khả năng kết nối chúng thành một quy trình làm việc liên mạch. Ứng viên mạnh không chỉ liệt kê tên công cụ mà mô tả rõ cách sử dụng từng công cụ trong ngày làm việc thực tế - từ theo dõi Jira board, xem kết quả CI/CD buổi sáng, viết script Playwright buổi trưa đến ghi nhận lỗi với video bằng Loom buổi chiều. Điểm cộng nếu ứng viên đề cập đến việc tích hợp giữa các công cụ, ví dụ kết nối Jira với TestRail để tự động cập nhật trạng thái thực thi. Nhà tuyển dụng có thể hỏi thêm: "Bạn đã bao giờ phải tự thiết lập toàn bộ hệ thống công cụ cho một dự án mới từ đầu chưa?"

Question 15

Ngoài functional testing, bạn đã test non-functional requirements chưa? Cho ví dụ về security testing hoặc accessibility testing bạn đã thực hiện.

Accepted Answer

NFR types -> Security testing examples -> Accessibility basics -> Tools used. Nhà tuyển dụng đánh giá độ rộng trong hiểu biết về kiểm thử phi chức năng - một điểm yếu phổ biến của QA Việt Nam khi phần lớn chỉ tập trung kiểm thử chức năng. Câu trả lời tốt mô tả cụ thể những gì đã thực hiện: với kiểm thử bảo mật - kiểm tra SQL injection, XSS, IDOR, xác thực phiên làm việc và biết OWASP Top 10; với kiểm thử khả năng tiếp cận - dùng trình đọc màn hình, kiểm tra tương phản màu sắc theo WCAG AA, điều hướng bàn phím và văn bản thay thế cho hình ảnh. Điểm cộng lớn nếu ứng viên có kinh nghiệm thực tế với kiểm thử khả năng tiếp cận vì đây là kỹ năng cực kỳ hiếm trong ngành tại Việt Nam. Nhà tuyển dụng thường hỏi tiếp: bạn ưu tiên loại kiểm thử phi chức năng nào khi thời gian có hạn?

Question 16

Nhiều người nghĩ QA là bước đệm để chuyển sang dev. Bạn nghĩ sao về career path của QA và tại sao bạn chọn ở lại testing?

Accepted Answer

Perspective on QA career -> Personal motivation -> Growth direction (QA Lead, SDET, QA Manager). Nhà tuyển dụng đánh giá mức độ cam kết lâu dài với nghề kiểm thử và sự rõ ràng trong định hướng phát triển, không chỉ tìm ứng viên chọn QA vì "dễ vào nghề IT". Câu trả lời tốt cho thấy ứng viên thực sự thấy giá trị trong công việc kiểm thử - ví dụ tư duy detective khi tìm lỗi mà dev không thấy - và có lộ trình rõ ràng: hướng SDET để kết hợp coding với tư duy kiểm thử, hoặc chuyên sâu vào kiểm thử hiệu suất hay bảo mật. Điểm cộng nếu ứng viên nêu mục tiêu cụ thể trong 2-3 năm tới (QA Lead, SDET, quản lý team) và liên kết với cơ hội tại công ty đang phỏng vấn. Câu trả lời "sẽ chuyển sang dev sau" không phải xấu nhưng cần trung thực và không làm ứng viên trông thiếu cam kết.

Question 17

Mức lương bạn mong muốn là bao nhiêu?

Accepted Answer

Market research -> State range -> Justify with skills/certifications -> Total compensation. Nhà tuyển dụng đánh giá khả năng tự định giá bản thân dựa trên dữ liệu thị trường, không chỉ nói "tùy công ty". Ứng viên nên nêu mức kỳ vọng cụ thể kèm lý giải rõ ràng dựa trên số năm kinh nghiệm, kỹ năng tự động hóa và chứng chỉ như ISTQB - QA biết automation thường cao hơn manual 30-50%, có thêm performance testing hoặc security testing thì cao hơn 15-20% nữa. Điểm cộng nếu ứng viên chủ động hỏi lại về chu kỳ đánh giá lương, thưởng và ngân sách đào tạo. Tham khảo mặt bằng thị trường VN T8/2026: Junior 10-18 triệu, Mid 18-30 triệu, Senior/Automation 28-50 triệu, Lead 40-65 triệu (gross); số liệu thực tế có thể khác tùy công ty và ngành.

Question 18

Bạn có câu hỏi nào cho chúng tôi không?

Accepted Answer

2-3 câu hỏi: về QA process, tools, team structure, growth. Nhà tuyển dụng đánh giá mức độ nghiên cứu của ứng viên và khả năng tự đánh giá sự phù hợp với môi trường làm việc. Ứng viên giỏi chuẩn bị câu hỏi thể hiện tư duy QA chuyên nghiệp - hỏi về độ phủ tự động hóa hiện tại, tỷ lệ QA/dev, mức độ QA tham gia sprint planning, và lộ trình lên QA Lead. Đây là cách ứng viên thể hiện rằng họ đang đánh giá mức độ trưởng thành của quy trình QA tại công ty, không chỉ đơn thuần xin việc. Tránh các câu hỏi về giờ làm hay chế độ tăng ca ngay trong buổi phỏng vấn đầu tiên.