Mock interview tester 2026: 40 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
Đánh dấu câu hỏi sau khi tự trả lời và đối chiếu 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.
Lý thuyết QA: 20 khái niệm dễ nhầm lẫn
Đây không phải bài kiểm tra học thuộc câu chữ ISTQB. Người phỏng vấn có thể hỏi định nghĩa đơn giản rồi yêu cầu ví dụ trong sản phẩm. Hãy giải thích sự khác biệt bằng lời của mình và cho thấy nó thay đổi quyết định kiểm thử như thế nào.
Các chủ đề bám theo CTFL 4.0.1 chính thức: mục tiêu và nguyên tắc, quy trình, cấp độ và loại kiểm thử, static testing, test design, rủi ro và kết thúc. Câu hỏi và ví dụ ở đây do chúng tôi biên soạn, không phải đề thi chính thức.
21QA, QC và testing khác nhau thế nào?
Phân tích câu trả lời mạnh
QA chú trọng ngăn ngừa vấn đề trong cách xây dựng sản phẩm: yêu cầu, acceptance criteria, review và quy trình nhóm. QC đánh giá chất lượng sản phẩm đã tạo; testing là một cách đánh giá đó. Chức danh trong công ty không phải ranh giới cứng: QA engineer có thể vừa review yêu cầu vừa chạy test. Với payment, làm rõ quy tắc làm tròn trước khi phát triển giúp tránh lỗi; kiểm số tiền thực tế qua API giúp phát hiện lỗi đã tồn tại.
Đang đánh giá: phân biệt quy trình với sản phẩm và trách nhiệm chất lượng của cả nhóm.
Dấu hiệu yếu: coi QA đồng nghĩa với manual testing hoặc hứa sản phẩm không có lỗi.
22Quy trình kiểm thử gồm những hoạt động nào?
Phân tích câu trả lời mạnh
Quy trình tùy bối cảnh gồm lập kế hoạch, theo dõi và điều chỉnh, phân tích cơ sở kiểm thử, thiết kế test, chuẩn bị dữ liệu và môi trường, thực thi, đánh giá tiêu chí kết thúc và tổng kết. Đây không nhất thiết là chuỗi cứng: exploratory testing kết hợp học hỏi, thiết kế và thực thi. Trong CRM, trước hết làm rõ ai được convert lead, mô hình hóa trạng thái và role, chuẩn bị hai account, chạy kiểm tra rồi báo cáo rủi ro còn lại. Checklist và báo cáo có thể hữu ích hơn hàng trăm case quá chi tiết.
Đang đánh giá: phân biệt kiểm cái gì với kiểm như thế nào, kể cả dữ liệu và bước tổng kết.
Dấu hiệu yếu: rút gọn quy trình thành viết test case, chạy và tạo bug.
23Verification khác validation ở điểm nào?
Phân tích câu trả lời mạnh
Verification hỏi sản phẩm có đúng yêu cầu đã đặc tả không; validation hỏi kết quả có đáp ứng nhu cầu thật của người dùng không. Cả hai đều cần. LMS có thể yêu cầu cấp chứng chỉ khi điểm quiz đạt 80%; test xác nhận rule đó, nhưng nghiên cứu người học có thể cho thấy họ còn phải hoàn thành bài bắt buộc. Đừng đồng nhất verification chỉ với kiểm tra tĩnh hoặc validation chỉ với chạy phần mềm: phương pháp phụ thuộc bối cảnh.
Đang đánh giá: hai câu hỏi khác nhau và ví dụ đúng đặc tả nhưng chưa phù hợp nhu cầu.
Dấu hiệu yếu: đọc thuộc khẩu hiệu mà không có ví dụ và giới hạn áp dụng.
24Các nguyên tắc kiểm thử là gì? Pesticide paradox nghĩa là gì?
Phân tích câu trả lời mạnh
Bảy nguyên tắc cổ điển: test cho thấy lỗi chứ không chứng minh không có lỗi; không thể kiểm hết; kiểm sớm tiết kiệm công sức; lỗi thường tập trung; bộ test không đổi giảm khả năng tìm lỗi mới; kiểm thử phụ thuộc bối cảnh; không tìm thấy lỗi vẫn vô ích nếu sản phẩm sai nhu cầu. Pesticide paradox mô tả việc một bộ test lặp mãi không phát hiện vấn đề mới. Cần xem lại regression suite theo thay đổi code, rủi ro mới và dữ liệu production, đồng thời giữ những test cũ còn giá trị.
Đang đánh giá: hệ quả thực tế đối với việc cập nhật bộ test.
Dấu hiệu yếu: xóa hết test cũ hoặc cho rằng suite xanh chứng minh không còn bug.
25Test level khác test type thế nào?
Phân tích câu trả lời mạnh
Level mô tả đối tượng và ranh giới: component, component integration, system, system integration hoặc acceptance. Type mô tả mục tiêu hay đặc tính chất lượng: chức năng, hiệu năng, bảo mật, usability và hơn nữa. Cùng một type có thể xuất hiện ở nhiều level. Có thể kiểm authorization trong unit test của policy, API integration và browser flow. Với chuyển tiền, unit kiểm phí, API kiểm tính giao dịch, system kiểm số dư và lịch sử, acceptance kiểm business rule.
Đang đánh giá: phân biệt kiểm ở đâu/cái gì với kiểm vì mục tiêu nào.
Dấu hiệu yếu: xếp smoke, regression và unit test vào cùng một thang cấp độ.
26Static testing tìm được gì khi chưa chạy code?
Phân tích câu trả lời mạnh
Kiểm thử tĩnh xem xét yêu cầu, thiết kế, test và source code mà không thực thi phần mềm đang kiểm, qua review hoặc công cụ phân tích. Nó phát hiện mâu thuẫn, role bị bỏ sót, nhánh không tới được và tiêu chí mơ hồ. Trong CRM, “manager xem được client” không nói rõ client của mình hay của tất cả; hỏi ngay lúc review rẻ hơn sửa data leak sau release. Dynamic testing vẫn cần để xác nhận hành vi thực tế.
Đang đánh giá: ví dụ lỗi trong yêu cầu và vai trò QA trước khi chạy sản phẩm.
Dấu hiệu yếu: coi static testing chỉ là linter hoặc cho rằng nó chứng minh app chạy đúng.
27Equivalence partitioning khác boundary value analysis thế nào?
Phân tích câu trả lời mạnh
Partition chia đầu vào thành nhóm dự kiến được xử lý giống nhau; lấy một đại diện giúp giảm số test. Boundary analysis chọn điểm chuyển giữa các nhóm có thứ tự, nơi dễ nhầm điều kiện bao gồm. Với số nguyên 1–99, có nhóm dưới, trong, trên khoảng; null, chuỗi và trường bị thiếu là nhóm riêng. Biên hai giá trị: 0/1 và 99/100; cách ba giá trị thêm 2 và 98. Nếu 0 có ý nghĩa gói giá đặc biệt, đó là business partition riêng.
Đang đánh giá: giải thích vì sao chọn giá trị và phân biệt biên số với loại đầu vào.
Dấu hiệu yếu: chỉ liệt kê 0, 1, 2 mà không nói rule và kết quả mong đợi.
28Khi nào dùng decision table và state-transition testing?
Phân tích câu trả lời mạnh
Decision table phù hợp khi kết quả phụ thuộc tổ hợp điều kiện: giảm giá chỉ dành cho khách đang hoạt động, đúng gói và không có nợ quá hạn. Mỗi dòng nêu tổ hợp và hành động mong đợi; đánh dấu tổ hợp không thể có. State-transition testing phù hợp khi trạng thái trước và sự kiện quan trọng: lead new → qualified → converted. Convert lần hai có thể bị cấm dù request có cùng dữ liệu. Kiểm cả chuyển đổi hợp lệ, không hợp lệ, lặp lại và tác dụng phụ.
Đang đánh giá: chọn kỹ thuật theo cấu trúc của rule.
Dấu hiệu yếu: kiểm từng điều kiện riêng mà bỏ sót tổ hợp hoặc lịch sử trạng thái.
29Test coverage là gì và vì sao 100% line coverage chưa phải chất lượng?
Phân tích câu trả lời mạnh
Coverage là tỷ lệ phần tử đã kiểm trong một mô hình được chọn: yêu cầu, nhánh code, trạng thái, role hoặc rủi ro. Phần trăm không có mẫu số sẽ ít ý nghĩa. 100% line coverage chỉ cho biết dòng đã chạy; không chứng minh assertion hữu ích, mọi nhánh, negative case hay nhu cầu người dùng. Báo cáo tốt nói rõ đã kiểm 12/14 yêu cầu quan trọng và 4/5 role, nêu hai vùng chưa kiểm và lý do để nhóm đánh giá rủi ro còn lại.
Đang đánh giá: nêu mô hình coverage rõ ràng và khoảng trống thật.
Dấu hiệu yếu: coi phần trăm coverage là phần trăm chất lượng sản phẩm.
30Làm sao quyết định có thể kết thúc kiểm thử?
Phân tích câu trả lời mạnh
Thống nhất exit criteria từ trước: luồng quan trọng đã kiểm, không còn blocker chưa xử lý, biết kết quả và vùng chưa kiểm, đã đánh giá rủi ro và có quyết định của release owner. Deadline ảnh hưởng scope nhưng không tự chứng minh chất lượng. Lỗi thu tiền hai lần không an toàn dù 95% test pass; lỗi cosmetic có thể được phát hành khi rủi ro còn lại được ghi nhận. QA cung cấp bằng chứng và khuyến nghị chứ không tự mình đóng dấu “được release”.
Đang đánh giá: exit criteria, rủi ro mở và người chịu trách nhiệm quyết định.
Dấu hiệu yếu: “khi không còn bug” hoặc “khi chạy hết case” mà không đánh giá rủi ro.
31Test oracle là gì và expected result lấy từ đâu?
Phân tích câu trả lời mạnh
Oracle là nguồn dùng để đánh giá hành vi thực tế: requirement, business invariant đã thống nhất, API contract, phép tính độc lập, phiên bản trước hoặc hệ thống đáng tin cậy khác. Nó không nhất thiết là một tài liệu duy nhất. Với phí ngân hàng, trước tiên làm rõ tỷ lệ, thứ tự làm tròn, tiền tệ và thời điểm trừ. Tính ví dụ độc lập với API rồi so response, balance và statement. Sao chép kết quả API vào assertion chỉ đóng băng bug hiện có. Nếu các nguồn mâu thuẫn, hỏi người sở hữu rule, ghi giả định và rủi ro; đừng bịa expected. UX chưa được document có thể nghiên cứu so sánh, nhưng sở thích của tester chưa phải requirement được duyệt.
Đang đánh giá: oracle độc lập, nguồn mâu thuẫn và giới hạn của giả định.
Dấu hiệu yếu: lấy implementation hiện tại làm chân lý duy nhất hoặc gọi sở thích cá nhân là bug.
32Đánh giá rủi ro kiểm thử bằng xác suất, tác động và độ tin cậy thế nào?
Phân tích câu trả lời mạnh
Rủi ro là vấn đề có thể xảy ra với khả năng và hậu quả, chưa phải defect đã xác nhận. Ưu tiên dựa trên vùng code vừa đổi, độ phức tạp dependency, incident cũ, số user và data có thể bị ảnh hưởng, khả năng hoàn tác. Mất tiền trong trường hợp hiếm có thể quan trọng hơn lỗi cosmetic thường xuyên. Điểm 1–3 cho khả năng × tác động giúp so sánh nhưng phép nhân không thay thảo luận. Ghi riêng độ tin cậy: integration mới không có lịch sử lỗi vẫn có thể nguy hiểm vì chưa hiểu rõ. Test plan cần nêu căn cứ điểm, phép kiểm, residual risk và người quyết định. Cập nhật thứ tự khi có bằng chứng mới.
Đang đánh giá: phân biệt risk và defect, yếu tố khả năng/tác động, xử lý điều chưa biết.
Dấu hiệu yếu: xem điểm chủ quan là xác suất chính xác hoặc chỉ kiểm vùng từng có bug.
33Vòng đời defect thế nào và vì sao cần retest?
Phân tích câu trả lời mạnh
Tên status tùy tracker, nhưng thường bug được phát hiện, xác nhận, giao người sửa, đánh dấu fixed, chờ kiểm, xác minh rồi đóng hoặc mở lại. Duplicate, cannot reproduce, deferred và won’t fix cần lý do. Retest kiểm đúng bản sửa trên build và data phù hợp; regression kiểm các hành vi liên quan để tìm tác dụng phụ. Nếu click đôi không còn tạo hai payment nhưng retry sau timeout vẫn tạo trùng, bug chưa được sửa trọn. Ghi build, bước và các biến thể đã thử. Fixed trong tracker là tuyên bố, không phải bằng chứng. Nếu expected behavior đổi, xác nhận rule mới với product owner trước khi đóng bug cũ.
Đang đánh giá: status so với bằng chứng, retest so với regression và reopen.
Dấu hiệu yếu: đóng bug ngay sau merge hoặc chỉ kiểm happy path ban đầu.
34Lỗi của con người, defect và failure khác nhau thế nào?
Phân tích câu trả lời mạnh
Error là hành động hoặc quyết định sai của con người: developer có thể hiểu “client của mình” thành “mọi client trong phòng”. Defect là thiếu sót trong requirement, code, data hoặc configuration phát sinh từ sai lầm đó. Failure là hành vi sai được quan sát khi chạy: manager B mở được card client của A. Không phải lúc nào cũng thấy toàn bộ chuỗi: defect có thể ngủ yên khi chưa gặp role và data phù hợp; failure cũng có thể liên quan môi trường hay dependency ngoài. Bug report nên nêu failure quan sát được và bằng chứng, không đoán suy nghĩ của developer. Phân tích nguyên nhân sau này có thể dẫn đến review requirement và access tests tốt hơn, nhưng screenshot một mình không chứng minh nguyên nhân.
Đang đánh giá: tách nguyên nhân, thiếu sót và tác động quan sát được.
Dấu hiệu yếu: coi mọi failure là bằng chứng cho một sai lầm cụ thể của developer.
35Smoke, sanity và regression trả lời câu hỏi gì?
Phân tích câu trả lời mạnh
Smoke là tập kiểm ngắn cho biết build còn đủ hoạt động để tiếp tục test không. Sanity là kiểm hẹp thay đổi cụ thể và vùng gần nó sau fix hay release nhỏ; cách dùng thuật ngữ tùy team nên làm rõ định nghĩa tại chỗ. Regression tìm hậu quả không mong muốn của thay đổi trên hành vi cũ. Sau sửa discount, smoke có thể kiểm login, catalog, checkout; sanity kiểm discount và boundary; regression kiểm tổ hợp promo, refund, client cũ và tổng tiền. Các tập có thể giao nhau: không cần chạy cùng một test ba lần vì nhãn. Điều quan trọng là nêu mục tiêu, scope và phần chưa kiểm.
Đang đánh giá: mục đích, thuật ngữ địa phương và ví dụ không lặp vô ích.
Dấu hiệu yếu: nói smoke xanh thay thế được phân tích ảnh hưởng của thay đổi.
36Kiểm yêu cầu phi chức năng “nhanh và tin cậy” thế nào?
Phân tích câu trả lời mạnh
Biến tính từ thành tiêu chí đo được: p95/p99 latency, tỷ lệ lỗi cho phép, lượng data, user đồng thời, cửa sổ đo, availability và recovery. Trung bình có thể che đuôi request chậm. Với tìm kiếm CRM, thống nhất kích thước database, loại query và mục tiêu p95 dưới workload xác định; đo cache nguội và ấm riêng. Với độ tin cậy, kiểm timeout, retry, idempotency và queue phục hồi khi dependency lỗi. QA environment nhỏ không tương đương production, nên ghi giới hạn thay vì tuyên bố SLO sai. Xác định workload, metric và ngưỡng pass/fail trước khi chạy.
Đang đánh giá: tiêu chí đo, tail latency, workload và giới hạn môi trường.
Dấu hiệu yếu: coi một request nhanh hay giá trị trung bình là chứng cứ hiệu năng.
37Chuẩn bị test data thế nào để các phép kiểm không ảnh hưởng nhau?
Phân tích câu trả lời mạnh
Mỗi scenario cần biết trạng thái ban đầu và sở hữu data riêng. Với CRM, tạo account và client giả có prefix unique, đặt role và owner qua setup API hoặc fixture, rồi cleanup hay reset theo cách team thống nhất. Đừng dựa vào id cố định có thể đổi sau lần chạy khác. Test song song không nên chia sẻ một client hay promo code dùng một lần: một test có thể tiêu mất limit của test khác. Kiểm cả cleanup vì test crash có thể để lại data bẩn. Nếu không thể reset, ghi thứ tự chạy và giới hạn. Che token, thông tin cá nhân trong log; không cần khách hàng thật để tập luyện. Kiểm shared state riêng khi concurrency là mục tiêu scenario.
Đang đánh giá: trạng thái ban đầu, data unique, chạy song song và cleanup an toàn.
Dấu hiệu yếu: hard-code một id dùng chung rồi coi test đáng tin chỉ vì nó pass local.
38Shift-left nghĩa là gì và giới hạn ở đâu?
Phân tích câu trả lời mạnh
Shift-left là nhận feedback về chất lượng sớm hơn: review requirement, ví dụ acceptance criteria, static analysis, unit/component và contract tests trước end-to-end đắt đỏ. Không có nghĩa QA phải làm trước khi có code hay bỏ kiểm tra về sau. Trong CRM, hỏi ai được xem client sau đổi owner ở giai đoạn lập kế hoạch, kiểm policy và API, rồi đi qua hành trình thật của user. Kiểm sớm dễ chẩn đoán nhưng không thấy hết vấn đề cấu hình production, integration và cách dùng thật. Sau release vẫn cần metric lỗi quyền truy cập và flow thất bại. Chọn tín hiệu theo rủi ro và chi phí, không chỉ vị trí trong pipeline.
Đang đánh giá: hành động sớm cụ thể và lý do vẫn cần feedback ở system/production.
Dấu hiệu yếu: tuyên bố E2E không cần thiết hoặc chuyển hết trách nhiệm chất lượng sang QA.
39Nên đặt kiểm tra ở unit, API/contract hay E2E?
Phân tích câu trả lời mạnh
Chọn tầng ít tốn kém nhất mà vẫn quan sát đúng rủi ro. Unit kiểm nhiều boundary của công thức phí nhanh. API integration thấy ghi transaction, quyền, lỗi và idempotency. Contract bảo vệ thỏa thuận consumer/provider, kể cả client cũ còn hỗ trợ. E2E xác nhận user đi hết hành trình quan trọng và thấy kết quả. Không lặp mọi giá trị ở mọi tầng: vài smoke end-to-end nối các thành phần, tổ hợp lớn nằm ở tầng thấp. Test pyramid không phải luật tuyệt đối; tích hợp payment cần sandbox và mock không chứng minh contract thật. Mỗi test cần oracle, owner và chi phí duy trì hợp lý.
Đang đánh giá: chọn tầng theo rủi ro, tránh lặp mù quáng và hiểu giới hạn của mock.
Dấu hiệu yếu: tự động hóa mọi thứ qua browser hoặc xem unit coverage là bằng chứng integration.
40Nói gì khi yêu cầu chưa đủ hoặc bạn không biết đáp án?
Phân tích câu trả lời mạnh
Tách điều đã biết khỏi giả định. Nếu task CRM nói “việc quá hạn phải nổi bật” nhưng thiếu timezone, thời điểm chuyển và cách sort, hãy hỏi cụ thể, đề xuất giả định tạm thời và phép kiểm cho hai cách hiểu hợp lý. Nếu không nhớ HTTP status hay lệnh của tool, giải thích nguyên tắc mong đợi, chỉ ra specification cần tra và không bịa rule. Người phỏng vấn xem bạn nhận ra rủi ro nào, chọn thí nghiệm nào, mong đợi gì và chứng minh sai lệch ra sao. Sau khi rule rõ, cập nhật test. “Cần thống nhất trước khi định nghĩa oracle” là câu trả lời tốt khi contract thực sự thiếu; đoán chắc chắn thì không.
Đang đánh giá: xử lý bất định, giả định kiểm được và bước tiếp theo cụ thể.
Dấu hiệu yếu: bịa rule phổ quát hoặc im lặng thay vì phân rã vấn đề.
Tự đánh giá câu trả lời sau mock interview
Chấm chất lượng quyết định, không phải việc nhận ra thuật ngữ. Với mỗi câu, tự hỏi mình có nêu bối cảnh, nguồn expected result, data và hành động cụ thể, tác dụng phụ và bằng chứng sai lệch không. “Tôi sẽ kiểm API” không nói method, role, status hay trạng thái sau request. “Dùng hai manager, tạo client của A, gọi id bằng token B và kiểm bị từ chối cùng dữ liệu không đổi” đã có thể thành test thật. Đừng cho điểm tối đa chỉ vì gọi tên rủi ro mà chưa chỉ ra cách kiểm.
Với lý thuyết, dùng công thức “phân biệt → ví dụ → giới hạn”. Severity nói về tác hại, priority nói về thứ tự sửa; đọc được CRM card của manager khác là nghiêm trọng dù hiếm gặp, nhưng team quyết định lịch sửa. Nếu đọc được định nghĩa mà không chỉ ra nó đổi quyết định sản phẩm thế nào, hãy học lại. Nếu ví dụ tốt nhưng quên một chữ chính xác, đó không phải thất bại: trong công việc quyết định thường quan trọng hơn câu chữ. Ghi các cặp dễ nhầm và tự tạo phản ví dụ.
Phân biệt thiếu kiến thức với lỗi quy trình. Không biết contract test kiểm gì: đọc tài liệu gốc và thử một ví dụ nhỏ. Biết access control nhưng quên hỏi owner của object: luyện nêu actor và state trước khi chọn request. Đưa ra nhiều test không có thứ tự: giới hạn thời gian và giải thích mỗi bước đầu bảo vệ rủi ro nào. Sau một lần tập, chỉ chọn ba chủ đề yếu. Ngày tiếp theo trả lời lại không nhìn gợi ý và xem đã có expected cùng evidence cụ thể chưa.
Đừng chỉ học thuộc đáp án mẫu. Đổi domain: thay chuyển tiền bằng chuyển đổi lead, hoặc CRM bằng chứng chỉ LMS. Sau đó đổi giới hạn: không có database access, còn một giờ, hoặc bug chỉ xảy ra khi có tải. Câu trả lời tốt giữ cấu trúc lập luận nhưng đổi phép kiểm và priority. Đó là hiểu vấn đề thay vì kể lại. Trong phỏng vấn thật, bạn có thể nói rule cần làm rõ; hãy tiếp tục bằng giả định kiểm được, các phương án và kế hoạch thu thập bằng chứng. Thử giải thích một defect cho ba đối tượng: developer cần bước, data và log; product owner cần tác động tới user và workaround; release owner cần khả năng, quy mô và residual risk. Giữ sự thật nhất quán, chỉ đổi mức chi tiết. Nếu chưa thể nói ngắn gọn điều gì sai và bằng chứng ở đâu, investigation có thể còn lỗ hổng. Hãy kiểm claim theo nguồn, không theo giọng nói tự tin.
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.