Mock interview tester 2026: 20 câu hỏi Junior và Middle QA
Đây là buổi diễn tập technical interview, không phải danh sách thuật ngữ để học thuộc. Hãy đặt giờ, trả lời thành tiếng rồi mới mở phần phân tích. Mỗi câu đều chỉ ra một câu trả lời mạnh cần có gì và lỗi nào thường làm ứng viên mất điểm.
Cách luyện mock interview hiệu quả
Phỏng vấn thật không chỉ kiểm kiến thức mà còn kiểm khả năng sắp xếp câu trả lời nhanh. Hãy dành 90 giây cho câu lý thuyết và tối đa 5 phút cho câu tình huống. Nói thành tiếng vì câu trả lời trong đầu thường mạch lạc hơn nhiều so với lúc nói ra.
Đừng học thuộc câu mẫu. Hãy so cấu trúc: bạn đã nêu mục tiêu, rủi ro, phép kiểm cụ thể, kết quả mong đợi và bằng chứng chưa? Cách tư duy đó quan trọng hơn câu chữ.
- Làm rõ bối cảnh và giới hạn
- Nêu rủi ro chính
- Đề xuất phép kiểm cụ thể
- Nói kết quả mong đợi
Chỉ tính hoàn thành khi bạn trả lời thành tiếng trước khi mở phần phân tích.
- 0 Không trả lời hoặc chỉ liệt kê thuật ngữ không liên quan tới vấn đề. 0 · thiếu kiến thức
- 1 Định nghĩa đúng nhưng thiếu ví dụ, expected result và ưu tiên. 1 · lý thuyết
- 2 Có cấu trúc, phép kiểm và expected result cụ thể nhưng ít nói về rủi ro và bằng chứng. 2 · Junior+
- 3 Câu trả lời xét bối cảnh, rủi ro, trade-off, observability và giải thích lựa chọn. 3 · Middle
Junior QA: nền tảng được kiểm qua ví dụ
Junior không cần là bách khoa toàn thư. Nhà tuyển dụng cần nền tảng chắc: test design, bug report rõ ràng, HTTP, client-server và khả năng nhìn thấy negative path.
1 Testing là gì và có thể chứng minh hệ thống không có bug không?
Phân tích câu trả lời mạnh
Testing cung cấp thông tin về chất lượng và giảm rủi ro, nhưng không chứng minh được không còn defect. Exhaustive testing hầu như không thể, nên các phép kiểm được chọn theo yêu cầu, rủi ro, kỹ thuật test design và lịch sử sản phẩm. Kết quả của QA không phải “không có bug”, mà là bức tranh rõ ràng về phần đã kiểm và rủi ro còn lại.
Đang đánh giá: mục tiêu testing, giới hạn coverage và mối liên hệ với rủi ro.
Dấu hiệu yếu: “QA đảm bảo sản phẩm hoạt động hoàn toàn” hoặc chỉ đọc một định nghĩa không có ý nghĩa thực tế.
2 Bạn sẽ test form đăng nhập thế nào?
Phân tích câu trả lời mạnh
Trước tiên tôi làm rõ các cách đăng nhập, quy tắc email/password, lockout, recovery và role. Sau đó kiểm login thành công, từng field, giá trị rỗng và biên, chữ hoa thường và khoảng trắng, sai cặp credential, chống brute force, thông báo lỗi và việc tạo session. Sau login, tôi kiểm truy cập trực tiếp trang bảo vệ, logout, session hết hạn và đổi user.
Đang đánh giá: câu hỏi làm rõ, nhóm test có cấu trúc và đi từ UI tới session và security.
Dấu hiệu yếu: một danh sách field dài không có ưu tiên và không kiểm điều gì xảy ra sau login.
3 Severity khác priority thế nào? Hãy cho ví dụ.
Phân tích câu trả lời mạnh
Severity mô tả mức ảnh hưởng tới hệ thống hoặc user; priority mô tả thời điểm business muốn sửa. Mất dữ liệu trong báo cáo nội bộ hiếm dùng có thể severity cao nhưng không phải priority cao nhất. Sai tên công ty ở trang chủ trước chiến dịch quảng cáo có severity thấp nhưng priority cao. Thang đo và người đặt field phụ thuộc quy trình team.
Đang đánh giá: phân biệt thiệt hại kỹ thuật và thứ tự business bằng ví dụ có hai mức khác nhau.
Dấu hiệu yếu: coi “QA đặt severity, manager đặt priority” là luật chung mà không giải thích ý nghĩa.
4 POST /orders trả về 201. Có thể coi test đã pass không?
Phân tích câu trả lời mạnh
Chưa. 201 chỉ kiểm một phần contract. Cần kiểm body và header, schema và giá trị order, Location nếu có, dữ liệu được lưu qua GET sau đó, thay đổi tồn kho và tổng tiền, cùng side effect ngoài ý muốn. Gửi lại request để xác định có nên tạo order thứ hai hay phải idempotent. Status thành công nhưng tổng tiền sai vẫn là defect.
Đang đánh giá: khả năng tách status, contract, dữ liệu và side effect thành các lớp kiểm riêng.
Dấu hiệu yếu: “201 nghĩa là Created nên đã đúng” hoặc chỉ nhìn status màu xanh trong Postman.
5 Authentication khác authorization thế nào?
Phân tích câu trả lời mạnh
Authentication xác nhận user là ai qua credential, token hoặc session. Authorization quyết định user đó được làm gì. Cần kiểm không token, token sai hoặc hết hạn, token đúng, role khác và object id của user khác. Theo HTTP, thiếu credential hợp lệ thường trả 401; user đã biết nhưng không có quyền thường trả 403, dù object riêng tư đôi khi được ẩn bằng 404.
Đang đánh giá: identity so với permission, role và quyền sở hữu object.
Dấu hiệu yếu: chỉ kiểm button bị ẩn trong UI mà không gửi request bị cấm trực tiếp.
6 Test case, checklist và exploratory session khác nhau thế nào?
Phân tích câu trả lời mạnh
Test case ghi rõ precondition, data, step và expected result; phù hợp với luồng quan trọng cần lặp lại, bàn giao hoặc audit. Checklist ngắn hơn và để tester tự chọn thao tác cụ thể, phù hợp với khu vực quen thuộc và regression nhanh. Exploratory session có charter, rủi ro và timebox; học sản phẩm, thiết kế test và thực thi diễn ra đồng thời, kết quả là note, finding và câu hỏi. Chọn format theo rủi ro, độ trưởng thành sản phẩm và chi phí tái hiện, không theo thói quen.
Đang đánh giá: mục đích của từng artefact và khả năng chọn mức chi tiết phù hợp.
Dấu hiệu yếu: gọi exploratory testing là click ngẫu nhiên hoặc bắt mọi phép kiểm phải có test case chi tiết.
7 HTTP method nào là safe và method nào idempotent?
Phân tích câu trả lời mạnh
Safe method được dùng để đọc: GET, HEAD, OPTIONS và TRACE không nên thay đổi state theo ý định của client. Idempotent nghĩa là lặp cùng request có expected effect trên server như gọi một lần; nhóm này gồm safe method, PUT và DELETE. HTTP không đảm bảo chung như vậy cho POST hoặc PATCH. DELETE lần hai có thể trả status khác và GET vẫn có thể tạo log: idempotency nói về effect được yêu cầu, không phải response giống từng byte hay mọi side effect nội bộ.
Đang đánh giá: phân biệt safe và idempotent, ý nghĩa với retry và việc response không cần giống hệt.
Dấu hiệu yếu: khẳng định mọi POST luôn tạo duplicate hoặc DELETE luôn phải trả cùng status.
8 Phân biệt 400, 401, 403, 404, 409 và 422 thế nào?
Phân tích câu trả lời mạnh
400 là client error chung như syntax request sai. 401 nghĩa là thiếu credential hợp lệ và response cần WWW-Authenticate challenge. 403 nghĩa là server hiểu nhưng từ chối thực hiện. 404 là resource không tồn tại hoặc được cố ý ẩn. 409 là xung đột với state hiện tại, ví dụ version cũ hoặc email đã dùng. 422 nghĩa là content type và syntax hợp lệ nhưng instruction không qua semantic validation. API contract quyết định code cụ thể; QA kiểm tính nhất quán của contract, không áp đặt code mình thích.
Đang đánh giá: semantics của status, liên hệ với contract và ví dụ phân biệt các code gần nhau.
Dấu hiệu yếu: coi mọi 4xx như nhau hoặc mong 401 cho user đã login nhưng không có quyền.
9 Kiểm session và logout thế nào ngoài việc bấm button?
Phân tích câu trả lời mạnh
Trước hết xác định session id được lưu và gửi ở đâu. Kiểm session rotation sau login, thuộc tính cookie Secure, HttpOnly, SameSite, token không nằm trong URL, truy cập resource trước và sau logout, replay request cũ, thiết bị thứ hai, idle timeout và absolute timeout. Logout phải làm server session hoặc refresh token mất hiệu lực theo model đã chọn, không chỉ redirect UI. Chỉ xóa localStorage chưa chứng minh access đã bị thu hồi.
Đang đánh giá: vòng đời session, replay request trực tiếp và nhiều client thay vì chỉ nhìn UI.
Dấu hiệu yếu: chỉ kiểm tên user biến mất hoặc yêu cầu cùng token phải lưu cả cookie và localStorage.
10 Tìm email trùng bằng SQL thế nào và sau đó kiểm gì?
Phân tích câu trả lời mạnh
Query khởi đầu: SELECT LOWER(TRIM(email)) AS normalized_email, COUNT(*) FROM users GROUP BY LOWER(TRIM(email)) HAVING COUNT(*) > 1. Việc normalize phải theo business rule; tester không thể tự coi hoa thường hay khoảng trắng là vô nghĩa. Sau đó lấy các row cụ thể để so tenant, status, deleted_at và thời gian tạo. Cuối cùng kiểm unique constraint ở lúc ghi và hai registration đồng thời. Tìm thấy duplicate cũ không chứng minh duplicate mới đã bị chặn.
Đang đánh giá: GROUP BY với HAVING, normalize có chủ ý và đi từ phân tích data tới nguyên nhân tạo duplicate.
Dấu hiệu yếu: dùng DISTINCT làm ẩn duplicate hoặc xóa row trước khi xác nhận business rule.
Middle QA: ưu tiên, bất định và ảnh hưởng tới sản phẩm
Middle không chỉ biết nhiều thuật ngữ hơn. Họ phải ra quyết định khi yêu cầu thiếu, thời gian ít, rủi ro xung đột và giải thích quyết định đó rõ ràng cho team.
11 API trả 202 Accepted. Bạn kiểm kết quả bất đồng bộ thế nào?
Phân tích câu trả lời mạnh
202 chỉ nói request đã được nhận, chưa nói xử lý xong. Kiểm job id hoặc status URL, transition queued sang processing rồi completed hoặc failed, timeout đã thống nhất, polling lặp và business effect cuối. Bao phủ worker lỗi, message được gửi lại, hai command giống nhau và dependency không hoạt động. Response đầu không được hứa thành công quá sớm; lỗi cuối phải hiện cho user và truy vết được bằng correlation id.
Đang đánh giá: phân biệt accepted và completed, eventual consistency, observability và duplicate delivery.
Dấu hiệu yếu: dừng test ở 202 hoặc dùng sleep cố định thay vì polling state có timeout.
12 Backend đổi một field API. Bạn kiểm backward compatibility thế nào?
Phân tích câu trả lời mạnh
Xác định mọi consumer và contract đã hứa: required, type, format, nullable, enum và ý nghĩa. Chạy client cũ với backend mới và, nếu rollout cho phép, client mới với backend cũ. Thêm field optional thường compatible; xóa, đổi tên, đổi type hoặc thêm enum bắt buộc có thể làm hỏng client. Kiểm unknown field, default, serialization, versioning và contract test. Kế hoạch migration cần thời gian chạy song song, metric dùng field cũ và ngày gỡ bỏ rõ ràng.
Đang đánh giá: tư duy theo consumer, cả hai hướng compatibility và rollout từng bước.
Dấu hiệu yếu: coi mọi thay đổi additive đều an toàn với strict parser hoặc chỉ test web client hiện tại.
13 Automated test thỉnh thoảng fail dù sản phẩm không đổi. Bạn làm gì?
Phân tích câu trả lời mạnh
Giữ trace, screenshot, network và log của đúng run đó, rồi so một run pass với một run fail. Phân loại nguồn có thể: wait và race condition, shared data, phụ thuộc thứ tự, network, hệ thống ngoài, clock hoặc defect sản phẩm thật sự không ổn định. Rerun giúp đo tần suất nhưng không phải fix. Test bị quarantine cần owner, deadline và signal vẫn nhìn thấy. Sửa condition bằng observable wait, data độc lập hoặc contract ổn định thay vì sleep vô điều kiện.
Đang đánh giá: chẩn đoán dựa trên bằng chứng, flaky test so với flaky product và quarantine có trách nhiệm.
Dấu hiệu yếu: retry đến khi xanh hoặc xóa test trước khi hiểu lỗi.
14 Bạn kiểm feature nằm sau feature flag thế nào?
Phân tích câu trả lời mạnh
Lập matrix flag off/on, account mới/cũ, role hoặc cohort, web/API, cache và nhiều instance. Off phải giữ hành vi cũ; on phải bao phủ luồng mới và migration data. Kiểm chuyển flag không deploy, rollout theo phần trăm, không lộ feature sang cohort khác, metric và rollback. Khi rollout hoàn tất, cần xóa flag, nhánh code chết và test cũ; nếu không số trạng thái sẽ tăng mãi.
Đang đánh giá: cả hai trạng thái, segmentation, consistency, observability và toàn bộ vòng đời flag.
Dấu hiệu yếu: chỉ kiểm trạng thái on trong một browser hoặc quên data cũ và rollback.
15 QA nên kiểm gì sau khi deploy production?
Phân tích câu trả lời mạnh
Trước release, thống nhất production smoke nhỏ dùng action read-only hoặc synthetic data an toàn, dashboard, threshold và điều kiện rollback. Sau deploy, kiểm health và version, user path quan trọng, tỷ lệ 4xx/5xx, latency, queue, business metric và log theo correlation id. So với baseline và tách ảnh hưởng của release khỏi noise thường ngày. Ghi lại thời gian, version, phép kiểm, quan sát và quyết định tiếp tục rollout hay rollback.
Đang đánh giá: an toàn production, signal kỹ thuật và business, cùng stop condition định trước.
Dấu hiệu yếu: thử nghiệm trên record khách hàng thật hoặc tuyên bố thành công chỉ vì homepage mở được.
16 Ngày mai release nhưng full regression mất hai ngày. Bạn làm gì?
Phân tích câu trả lời mạnh
Tôi thu thập thay đổi và vùng ảnh hưởng, xác định business flow quan trọng rồi chọn test theo xác suất và mức thiệt hại. Ưu tiên smoke, phần vừa đổi, tiền, access, mất dữ liệu, integration và vùng hay có defect. Tôi nói rõ phần chưa cover và residual risk mà team chấp nhận. Nếu rủi ro không chấp nhận được, đề xuất giảm scope hoặc dời release.
Đang đánh giá: risk-based testing, minh bạch coverage và đưa ra phương án hữu ích.
Dấu hiệu yếu: “tôi sẽ ở lại test hết” mà không xét tính khả thi, hoặc bỏ test ngẫu nhiên.
17 Bug chỉ tái hiện khoảng một lần trong mười lần. Bạn điều tra thế nào?
Phân tích câu trả lời mạnh
Tôi ghi lại environment, account, data, thời gian và sequence chính xác; thu thập log, Network và correlation id. Tôi thay đổi từng yếu tố một: browser, network, hành động lặp, data volume và concurrency. So sánh request thành công với thất bại và đo tần suất trên một chuỗi thử. Bug ảnh hưởng lớn vẫn cần report với bằng chứng và hypothesis được ghi rõ là giả thuyết.
Đang đánh giá: kỷ luật thí nghiệm, thu thập bằng chứng và không biến suy đoán thành nguyên nhân.
Dấu hiệu yếu: đóng bug là “không tái hiện” sau hai lần hoặc viết nguyên nhân đoán được như sự thật.
18 Yêu cầu nói: “search phải nhanh và tiện”. Bạn test thế nào?
Phân tích câu trả lời mạnh
Tôi biến tính từ thành tiêu chí đo được: data volume, response time chấp nhận được, field được search, partial match, hoa thường, layout bàn phím, typo, sort và empty result. Trước khi làm rõ, tôi có thể exploratory test hành vi và rủi ro, nhưng không gọi kỳ vọng chủ quan là defect. Kết quả là danh sách câu hỏi cho product owner và draft test với assumption rõ ràng.
Đang đánh giá: testability của requirement và phân biệt câu hỏi với defect đã xác nhận.
Dấu hiệu yếu: tự quyết “nhanh” là hai giây rồi report mọi khác biệt thành bug.
19 Manager CRM nhìn thấy client của manager khác. Bạn kiểm và report thế nào?
Phân tích câu trả lời mạnh
Tôi dùng hai account cùng role và object thuộc A. Với token của B, tôi gọi id đó qua UI và trực tiếp qua API, rồi kiểm cả read và update. Report gồm hai account, role, object id, request và response, đồng thời che personal data. Đây có thể là Broken Object Level Authorization nên cần escalate theo security process của team.
Đang đánh giá: horizontal authorization, khả năng tái hiện và xử lý dữ liệu nhạy cảm cẩn thận.
Dấu hiệu yếu: chỉ report button nhìn thấy hoặc đính kèm customer data chưa che vào tracker công khai.
20 Double-click tạo hai payment. Ngoài button bạn kiểm gì?
Phân tích câu trả lời mạnh
Tôi kiểm click nhanh, gửi lại cùng HTTP request, retry sau timeout, cùng và khác idempotency key, request song song và retry từ thiết bị khác. Mỗi bước so response API, số operation và balance cuối. Disable button tốt cho UX nhưng backend phải đảm bảo vì request có thể được lặp mà không qua UI.
Đang đánh giá: idempotency, race condition và khác biệt giữa UI protection với server guarantee.
Dấu hiệu yếu: chỉ dừng ở disabled button và không replay request trực tiếp.
Bài tập API trong 10 phút
Yêu cầu: manager chỉ được đọc client của mình. Không đổi data trên server, hãy thiết kế bộ request nhỏ nhất để kiểm rule này. Sau đó mở phần đánh giá.
GET /api/clients/{id}\nAuthorization: Bearer {token}\n\nmanager_a owns client 481\nmanager_b owns client 927
Câu trả lời tốt bao phủ biên của access model, không chỉ một foreign id:
- A gọi 481: chờ 200 và dữ liệu client của A.
- B gọi 927: chờ 200 và dữ liệu client của B.
- A gọi 927 và B gọi 481: chờ 403 hoặc 404 theo contract.
- Không token và token sai: chờ 401.
- Id không tồn tại: kiểm 404 đã thống nhất và không làm lộ khác biệt giữa object của người khác với object không có.
Xem tiêu chí đánh giá
Mức tối thiểu là hai request positive và hai request chéo. Ứng viên mạnh thêm no-auth, id không tồn tại, thay đổi qua PATCH/DELETE và kiểm field thừa trong response. Ứng viên rất mạnh sẽ hỏi trước foreign object cần trả 403 hay được ẩn bằng 404 thay vì tự nghĩ ra contract.
Kế hoạch chuẩn bị trong 7 ngày
Câu hỏi thường gặp khi chuẩn bị
Technical interview QA kéo dài bao lâu?
Thường 45–90 phút, nhưng format tùy công ty: lý thuyết, kinh nghiệm, tình huống, API/SQL hoặc take-home task riêng. Hỏi recruiter trước về cấu trúc là hoàn toàn bình thường.
Junior tester có cần biết SQL và Postman trong năm 2026 không?
Với nhiều vị trí manual QA, nền tảng chắc là đủ: đọc JSON, gửi request có params và auth, kiểm response, viết SELECT với WHERE và JOIN đơn giản. Biết áp dụng quan trọng hơn đọc tên command.
Có thể nói “tôi không biết” không?
Có. Hãy nói rõ giới hạn và cách bạn sẽ tìm ra: làm rõ contract, đọc documentation, tái hiện request hoặc xem log. Một câu trả lời tự tin nhưng bịa nguy hiểm hơn khoảng trống kiến thức.
Làm sao biết mình đã sẵn sàng?
Bạn sẵn sàng khi có thể giải thích quyết định không cần note, nêu expected result và đặt câu hỏi hữu ích cho tình huống lạ. Không cần trả lời hoàn hảo mọi câu có thể xuất hiện.
Chuẩn bị tốt không phải là đọc xong một trăm đáp án, mà là có thể phân tích một task mới thành tiếng: làm rõ, chọn rủi ro, đề xuất phép kiểm và nêu bằng chứng.