Câu hỏi phỏng vấn Tester và QA ngày càng xoay quanh tình huống thật: không có tài liệu, deadline gấp, dev nói "không phải bug", lỗi lọt ra production. Thuộc định nghĩa kiểm thử hộp đen, hộp trắng là chưa đủ; người phỏng vấn muốn nghe cách bạn suy nghĩ, ưu tiên và giao tiếp. Bài này gom 30 câu hỏi theo 6 nhóm, mỗi câu kèm gợi ý những ý nên có trong câu trả lời và ví dụ ngắn.
Nhóm 1: Tư duy kiểm thử khi thiếu thông tin
1. Test một tính năng hoàn toàn mới khi không có tài liệu thế nào?
Bắt đầu bằng việc thu thập thông tin từ nguồn khác: hỏi PO, dev, xem thiết kế giao diện, ticket, phiên bản tương tự của đối thủ. Viết lại hiểu biết của mình thành danh sách yêu cầu ngắn và nhờ PO xác nhận. Song song, làm exploratory testing theo phiên có mục tiêu để khám phá hành vi, ghi lại câu hỏi và rủi ro. Kết quả nên là một bộ test case tối thiểu cho luồng chính và danh sách điểm cần làm rõ.
2. Deadline rất gấp, quyết định test cái gì trước?
Dùng rủi ro để ưu tiên: luồng tạo ra doanh thu hoặc dữ liệu quan trọng (đăng nhập, thanh toán, đặt hàng), phần code vừa thay đổi nhiều, phần từng có nhiều lỗi, phần nhiều người dùng nhất. Chạy smoke test cho luồng chính trước, sau đó mới mở rộng. Quan trọng là báo rõ cho team phần nào đã test, phần nào chưa, rủi ro còn lại là gì, để quyết định phát hành là quyết định chung.
3. Dev nói "không phải bug" nhưng bạn tin đó là bug, xử lý ra sao?
Không tranh luận bằng cảm tính. Đối chiếu với yêu cầu, thiết kế hoặc hành vi người dùng mong đợi; đưa bằng chứng tái hiện (bước, dữ liệu, ảnh, video, log). Nếu yêu cầu không rõ, đưa PO hoặc người nắm nghiệp vụ vào quyết định. Kết quả có thể là bug, là thay đổi yêu cầu, hoặc là cải tiến ghi vào backlog; điều quan trọng là được ghi nhận và có người quyết định.
4. Production lỗi nghiêm trọng sau khi release, bạn làm gì đầu tiên?
Xác nhận và tái hiện lỗi nhanh, xác định phạm vi ảnh hưởng (bao nhiêu người dùng, chức năng nào), báo ngay cho người phụ trách sự cố. Hỗ trợ quyết định rollback hoặc hotfix. Sau khi khắc phục, kiểm tra lại bản sửa và các phần liên quan, rồi tham gia phân tích vì sao lỗi lọt qua để bổ sung test case hoặc thay đổi quy trình.
5. Làm sao giảm số bug lọt ra production?
Tham gia sớm từ khâu đọc yêu cầu để phát hiện chỗ mơ hồ; cùng dev viết tiêu chí chấp nhận rõ; tăng unit test và API test ở phần lõi; có bộ regression tự động chạy trong CI; kiểm thử trên dữ liệu gần thật; phân tích các bug đã lọt để tìm điểm yếu chung; theo dõi lỗi sau release bằng log và báo cáo người dùng.
6. Đo chất lượng sản phẩm bằng cách nào?
Kết hợp nhiều chỉ số thay vì một con số: số bug lọt ra production theo mức độ nghiêm trọng, thời gian phát hiện và sửa, tỷ lệ test tự động chạy ổn định, độ phủ yêu cầu bằng test, số lượng khiếu nại của người dùng, số đo hiệu năng và độ ổn định. Nên nói rằng số lượng test case nhiều không đồng nghĩa với chất lượng cao.
7. Yêu cầu thay đổi liên tục, làm sao không sót case?
Liên kết test case với yêu cầu hoặc user story để khi yêu cầu đổi thì biết test nào cần sửa; tham gia buổi làm rõ yêu cầu ở mỗi sprint; giữ test case ở mức đủ ngắn để dễ cập nhật; dựa vào regression tự động cho phần ổn định và dành thời gian exploratory cho phần mới thay đổi.
Nhóm 2: Thiết kế test case
8. Test một API chưa có giao diện thế nào?
Đọc tài liệu API (OpenAPI/Swagger) hoặc hỏi dev về endpoint, tham số, mã lỗi. Dùng công cụ gửi request như Postman, curl hoặc công cụ test API để kiểm tra: dữ liệu hợp lệ và không hợp lệ, thiếu trường bắt buộc, sai kiểu, giới hạn độ dài, phân quyền (token của người khác, token hết hạn), mã trạng thái HTTP, thời gian phản hồi, và dữ liệu trong database sau khi gọi. Nếu có file OpenAPI, công cụ test theo Swagger giúp gọi thử từng endpoint nhanh hơn.
9. Thiết kế test case sao cho không trùng mà vẫn đủ độ phủ?
Dùng kỹ thuật thiết kế có hệ thống thay vì liệt kê theo cảm hứng: phân vùng tương đương, giá trị biên, bảng quyết định cho nhiều điều kiện kết hợp, chuyển trạng thái cho luồng có trạng thái, pairwise cho nhiều tham số. Lập ma trận truy vết giữa yêu cầu và test case để thấy chỗ trống và chỗ trùng.
10. Giá trị biên và phân vùng tương đương khác nhau, khi nào dùng?
Phân vùng tương đương chia dữ liệu đầu vào thành các nhóm được xử lý giống nhau, mỗi nhóm chỉ cần một giá trị đại diện. Giá trị biên kiểm tra ngay tại và sát ranh giới giữa các nhóm, nơi lỗi hay xảy ra nhất. Ví dụ ô tuổi chấp nhận 18–60: phân vùng là dưới 18, 18–60, trên 60; giá trị biên là 17, 18, 60, 61. Hai kỹ thuật thường dùng cùng nhau.
11. Exploratory testing là gì, khi nào dùng thay cho test case viết sẵn?
Là kiểm thử đồng thời học, thiết kế và thực hiện, dựa trên kinh nghiệm và quan sát. Hợp khi tính năng mới, tài liệu ít, thời gian ngắn, hoặc để tìm lỗi mà test case viết sẵn bỏ qua. Nên làm theo phiên có mục tiêu và thời lượng rõ, ghi chú những gì đã thử để có thể báo cáo và chuyển thành test case nếu cần.
12. Risk-based testing hoạt động thế nào trong dự án thực tế?
Liệt kê các chức năng, đánh giá từng chức năng theo hai trục: khả năng xảy ra lỗi (code mới, phức tạp, nhiều tích hợp) và mức ảnh hưởng nếu lỗi (tiền, dữ liệu, uy tín, pháp lý). Chức năng rủi ro cao được test sâu hơn, sớm hơn và tự động hóa trước. Bảng rủi ro cần được cập nhật mỗi khi phạm vi thay đổi.
13. Hệ thống quá lớn không thể test toàn bộ, làm thế nào?
Kết hợp ưu tiên theo rủi ro, phân tích ảnh hưởng của thay đổi (code nào đổi thì test vùng đó và vùng phụ thuộc), regression tự động cho luồng chính, và giám sát production để phát hiện sớm phần còn sót. Nói rõ với team rằng mục tiêu là giảm rủi ro xuống mức chấp nhận được, không phải chứng minh không còn lỗi.
Nhóm 3: Tự động hóa
14. Khi nào không nên tự động hóa test?
Khi tính năng còn thay đổi liên tục, khi test chỉ chạy một lần, khi kiểm tra cần cảm nhận của con người (giao diện có đẹp không, nội dung có dễ hiểu không), khi chi phí viết và bảo trì script lớn hơn lợi ích. Tự động hóa đáng làm nhất cho luồng ổn định, chạy lặp lại nhiều lần và có rủi ro cao.
15. Test pyramid là gì, vì sao nhiều team áp dụng sai?
Là mô hình gợi ý có nhiều unit test ở đáy (nhanh, rẻ), ít hơn integration hoặc API test ở giữa, và ít test giao diện đầu cuối nhất ở đỉnh (chậm, dễ vỡ). Sai lầm hay gặp là làm ngược thành "cây kem": hầu hết là test giao diện, chạy chậm và hay hỏng, trong khi unit test gần như không có.
16. Xử lý flaky test thế nào?
Flaky test là test lúc qua lúc trượt dù code không đổi. Đầu tiên cách ly test đó để không chặn pipeline, ghi nhận và theo dõi tần suất. Sau đó tìm nguyên nhân: chờ cố định bằng sleep thay vì chờ điều kiện, phụ thuộc thứ tự chạy, dùng chung dữ liệu, phụ thuộc mạng hoặc dịch vụ ngoài, múi giờ. Sửa gốc rồi mới đưa lại vào bộ chạy chính; không nên để cơ chế tự chạy lại che giấu vấn đề mãi.
17. Chọn test giao diện, API hay unit dựa trên tiêu chí gì?
Kiểm tra ở tầng thấp nhất có thể phát hiện được lỗi đó. Logic tính toán thì unit test; quy tắc nghiệp vụ, phân quyền, tích hợp giữa dịch vụ thì API test; luồng người dùng quan trọng và hiển thị thì test giao diện. Tầng càng thấp càng nhanh và ổn định, tầng càng cao càng gần trải nghiệm thật.
18. Làm automation chạy nhanh và ổn định trong CI/CD?
Chạy song song; tách bộ smoke chạy mỗi commit và bộ regression đầy đủ chạy định kỳ; mỗi test tự chuẩn bị và dọn dữ liệu của mình; dùng môi trường và dữ liệu cố định; giả lập dịch vụ ngoài không ổn định; chờ theo điều kiện thay vì chờ cứng; xuất báo cáo kèm ảnh chụp và log khi lỗi để dev xem ngay.
19. Mock và stub khác nhau thế nào?
Stub là bản thay thế trả về dữ liệu dựng sẵn để test chạy được, không quan tâm nó được gọi thế nào. Mock cũng thay thế phụ thuộc nhưng còn dùng để kiểm tra tương tác: có được gọi không, gọi bao nhiêu lần, với tham số gì. Nói ngắn gọn: stub phục vụ trạng thái, mock phục vụ kiểm tra hành vi.
20. Thuyết phục team đầu tư automation khi họ ngại chi phí?
Nói bằng số liệu của chính dự án: thời gian regression thủ công mỗi lần release, số lần release mỗi tháng, số bug regression đã lọt. Đề xuất bắt đầu nhỏ với luồng quan trọng nhất, đo thời gian tiết kiệm và số lỗi phát hiện sớm sau vài sprint, rồi mới mở rộng. Nêu cả chi phí bảo trì để kỳ vọng thực tế.
Nhóm 4: Quản lý bug
21. Bug nào phải sửa ngay, bug nào có thể để sau?
Sửa ngay khi bug chặn luồng chính, gây sai dữ liệu, mất tiền, lỗ hổng bảo mật hoặc vi phạm quy định. Có thể để sau khi ảnh hưởng nhỏ, có cách làm vòng, ít người gặp. Quyết định dựa trên mức nghiêm trọng, tần suất và chi phí sửa, và nên do PO cùng team chốt, tester cung cấp thông tin đủ để quyết định.
22. Severity và priority khác nhau thế nào trong thực tế?
Severity là mức độ ảnh hưởng kỹ thuật của lỗi lên hệ thống; priority là mức độ cần sửa sớm theo góc nhìn kinh doanh. Ví dụ: sai chính tả tên thương hiệu trên trang chủ có severity thấp nhưng priority cao; lỗi sập ở một màn hình quản trị hiếm dùng có severity cao nhưng priority có thể thấp hơn.
23. Viết bug report sao cho dev không cần hỏi lại?
Tiêu đề nêu rõ hiện tượng và vị trí; môi trường (phiên bản, trình duyệt, thiết bị, tài khoản thử); các bước tái hiện đánh số; kết quả thực tế và kết quả mong đợi; tần suất xảy ra; bằng chứng như ảnh, video, log, request và response; mức severity đề xuất. Một lỗi một báo cáo.
24. Không tái hiện được bug nhưng người dùng vẫn gặp, xử lý thế nào?
Thu thập thêm thông tin từ người dùng: thời điểm, thiết bị, tài khoản, thao tác trước đó. Tra log và hệ thống giám sát theo thời điểm đó. Thử các biến thể: dữ liệu khác, mạng chậm, nhiều tab, phiên đăng nhập hết hạn, múi giờ. Nếu vẫn không tái hiện được, đề nghị thêm log ở vùng nghi ngờ và theo dõi tiếp thay vì đóng bug.
25. Bạn từng bỏ sót bug chưa, đã cải thiện quy trình thế nào?
Câu này kiểm tra sự trung thực và khả năng học hỏi. Hãy kể một trường hợp thật: lỗi gì, vì sao bị sót (thiếu dữ liệu thử, hiểu sai yêu cầu, không test trên thiết bị đó), bạn đã thay đổi gì (bổ sung test case, checklist, tự động hóa, tham gia sớm hơn) và kết quả sau đó.
Nhóm 5: Hiệu năng, bảo mật, tương thích
26. Khi nào cần performance testing thay vì chỉ functional testing?
Khi hệ thống sắp chịu tải lớn (chiến dịch, sự kiện), khi có yêu cầu về thời gian phản hồi, khi thay đổi kiến trúc hoặc hạ tầng, khi người dùng phản ánh chậm. Functional test chỉ cho biết chức năng đúng hay sai với một người dùng; performance test cho biết hệ thống còn đúng không khi nhiều người dùng cùng lúc.
27. Kiểm tra khả năng chịu tải trước một chiến dịch lớn thế nào?
Ước lượng tải mục tiêu từ dữ liệu cũ và kế hoạch marketing; xác định luồng chính cần đo; chuẩn bị môi trường và dữ liệu gần thật; chạy kiểm thử tải tăng dần, kiểm thử chịu đựng trong thời gian dài, kiểm thử đột biến; theo dõi thời gian phản hồi, tỷ lệ lỗi và tài nguyên máy chủ; báo cáo ngưỡng chịu được và điểm nghẽn để team xử lý trước ngày chạy.
28. Tester nên chủ động kiểm tra những lỗi bảo mật phổ biến nào?
Dựa trên danh sách OWASP Top 10: kiểm soát truy cập sai (sửa ID trên URL để xem dữ liệu người khác), lỗi xác thực và phiên đăng nhập, chèn mã (SQL injection, XSS) qua ô nhập liệu, lộ dữ liệu nhạy cảm trong response hoặc log, cấu hình sai, tải lên file độc hại. Tester không thay được kiểm thử xâm nhập chuyên sâu nhưng bắt được nhiều lỗi cơ bản sớm.
29. Đảm bảo tương thích ngược khi phát hành phiên bản mới thế nào?
Chạy bộ regression của phiên bản cũ trên bản mới; test API với client phiên bản cũ (ứng dụng di động cũ vẫn gọi API); kiểm tra dữ liệu cũ vẫn hiển thị và xử lý đúng sau migration; kiểm tra file cấu hình và tích hợp với bên thứ ba. Ghi rõ trong ghi chú phát hành những gì thay đổi hành vi.
30. Test một quy trình deploy không gián đoạn để người dùng không bị ảnh hưởng thế nào?
Trong lúc deploy, chạy liên tục một luồng request giả lập người dùng và đo tỷ lệ lỗi, thời gian phản hồi; kiểm tra phiên đăng nhập không bị mất, giao dịch dở dang không bị hỏng; kiểm tra giai đoạn hai phiên bản cùng chạy không gây xung đột dữ liệu; thử rollback và xác nhận hệ thống trở lại bình thường. Phần này cần phối hợp với đội vận hành, xem thêm cách họ thiết kế deploy trong câu hỏi phỏng vấn DevOps.
Chuẩn bị thế nào cho vòng phỏng vấn Tester
Chuẩn bị ví dụ thật cho mỗi nhóm câu hỏi: một bug khó, một lần ưu tiên khi gấp, một lần cải tiến quy trình.
Luyện thiết kế test case tại chỗ: người phỏng vấn hay đưa một màn hình đăng nhập, giỏ hàng hoặc ô nhập ngày rồi yêu cầu liệt kê case trong vài phút.
Học thêm API và một ngôn ngữ script nếu muốn đi theo hướng automation. Lộ trình Software Tester/QA gợi ý thứ tự học.
Hiểu cách Backend xây hệ thống giúp bạn đặt câu hỏi kiểm thử sắc hơn, xem câu hỏi phỏng vấn Backend. Nếu bạn test web và muốn hiểu phía giao diện, tham khảo câu hỏi phỏng vấn Frontend và câu hỏi phỏng vấn JavaScript và TypeScript.
