Câu hỏi phỏng vấn QC Engineer (Middle–Senior–Lead)

Cách sử dụng tài liệu này#

Bộ 200 câu, gồm 46 Middle, 144 Senior, 10 Lead, chia thành 19 nhóm. Mức độ là gợi ý để luyện chiều sâu, không phải tiêu chuẩn chức danh tuyệt đối. 74 câu từ 21–94 tập trung vào SSO, OAuth/OIDC, IAM, E2EE và tích hợp giữa các lớp này.

• Trả lời thành tiếng trước khi đọc gợi ý. Với câu Senior/Lead, trình bày thêm rủi ro, cách tái hiện, oracle, evidence và trade-off.
• Mỗi câu có answer ngắn trên trang và explanation riêng qua tính năng giải thích của website; bản Markdown giải thích nằm trong file cùng tên có hậu tố -explanations.md.
• Câu hỏi về CV là khung chuẩn bị, không phải lời khẳng định bạn đã làm mọi kỹ thuật được đề cập. Chỉ thay bằng câu chuyện, vai trò và số liệu thực tế.
• Ví dụ ngoài CV, endpoint, schema, ngưỡng và đoạn code là giả định phục vụ luyện tập; cần điều chỉnh theo contract, version và môi trường thật.
• Xem hướng dẫn ôn và đối chiếu JD–CV để chọn thứ tự học và bộ câu cho từng vòng.

---

1. CV, kinh nghiệm thực tế và định vị ứng viên#

1. Hãy giới thiệu bản thân trong 90 giây cho vị trí này.#!

Mức độ: Middle.

Tóm tắt kinh nghiệm QC web/mobile, CIRCA và thế mạnh kiểm tra nghiệp vụ xuyên UI–API–database. Kết nối SSO/OAuth/IAM, Playwright và AI-assisted testing với nhu cầu công ty.

2. Bạn giải thích thế nào về “5+ years” và yêu cầu hai năm Senior/Lead?#!

Mức độ: Senior.

Đối chiếu thời gian thực tế; CV hiện liệt kê công việc từ 05/2022 và chức danh QC Engineer. Bổ sung kinh nghiệm trước đó nếu có, đồng thời nói rõ phạm vi ownership thay vì tự nhận chức danh Lead.

3. Phần nào trong Playwright workflow ở CIRCA do bạn trực tiếp xây dựng?#!

Mức độ: Middle.

Mô tả một flow cụ thể, cấu trúc test, fixture, assertion, dữ liệu và cách debug. Nêu rõ phần AI hỗ trợ và phần mình kiểm chứng, sửa hoặc thiết kế.

4. Kể một lỗi khó bạn điều tra bằng network, SQL và source code.#!

Mức độ: Senior.

Dùng khung bối cảnh → triệu chứng → giả thuyết → bằng chứng → nguyên nhân → xác minh fix. Lấy tình huống có thật và che dữ liệu nhạy cảm.

5. Bạn đã kiểm thử SSO/OAuth/IAM đến mức nào?#!

Mức độ: Middle.

Nêu hệ thống, vai trò người dùng, luồng đã kiểm tra và loại evidence đã thu thập. Phân biệt kiểm thử chức năng đăng nhập với xác minh token, session và phân quyền API.

6. Chuyển từ retail sang encrypted storage, bạn mang theo năng lực gì?#!

Mức độ: Senior.

Mang theo tư duy trạng thái, quyền truy cập, consistency, rollback, concurrency và điều tra lỗi. Bổ sung kiến thức threat model, vòng đời khóa và kiểm thử E2EE.

7. Bạn chứng minh AI giúp giảm công sức kiểm thử thế nào?#!

Mức độ: Middle.

So sánh tác vụ tương đương trước/sau, tính cả thời gian review và sửa đầu ra. Theo dõi thời gian hoàn thành, lỗi bỏ sót và chất lượng evidence.

8. CV có nhiều tools; bạn phân loại mức độ thành thạo ra sao?#!

Mức độ: Senior.

Tách đã dùng thường xuyên, từng áp dụng trong phạm vi nhỏ và đang học. Chuẩn bị một ví dụ kiểm chứng cho Playwright, Cypress, Detox, Postman, JMeter và agent-browser nếu từng dùng.

9. Làm việc trong nhóm hai người khác nhóm 30 người thế nào?#!

Mức độ: Middle.

Nhóm nhỏ cần ưu tiên rủi ro, phản hồi nhanh và tài liệu vừa đủ. Nhóm lớn cần ownership rõ, traceability, chuẩn báo lỗi và phối hợp dependency.

10. Bạn chuẩn bị câu chuyện STAR nào từ CV?#!

Mức độ: Senior.

Chuẩn bị các câu chuyện về lỗi nghiêm trọng, yêu cầu mơ hồ, cải tiến automation, phối hợp bất đồng và bài học sau release.

2. Nền tảng QC, thiết kế test và chiến lược#

11. QA, QC và testing khác nhau thế nào?#!

Mức độ: Middle.

QA chú trọng quy trình tạo chất lượng; QC đánh giá chất lượng đầu ra; testing là hoạt động tìm thông tin và phát hiện sai lệch. Thực tế vai trò có thể chồng lấn.

12. Bạn phân biệt test strategy, test plan và test case thế nào?#!

Mức độ: Middle.

Strategy định hướng theo rủi ro; plan xác định phạm vi, người, lịch, môi trường và tiêu chí; case mô tả điều kiện, hành động, dữ liệu và kết quả mong đợi.

13. Áp dụng equivalence partitioning và boundary value cho file upload thế nào?#!

Mức độ: Middle.

Chia nhóm kích thước hợp lệ/không hợp lệ, loại file và trạng thái quyền; kiểm tra sát ngưỡng, đúng ngưỡng, vượt ngưỡng và file rỗng theo contract.

14. Khi nào dùng decision table và state transition testing?#!

Mức độ: Senior.

Dùng decision table cho tổ hợp điều kiện tạo quyết định; dùng state transition cho hành vi phụ thuộc trạng thái và lịch sử.

15. Bạn ưu tiên test khi chỉ còn một ngày release thế nào?#!

Mức độ: Senior.

Xếp theo tác động, khả năng xảy ra, thay đổi gần đây và khả năng khôi phục. Ưu tiên mất dữ liệu, vượt quyền, giao dịch tiền và các luồng cốt lõi.

16. Smoke, sanity, regression và retest khác nhau thế nào?#!

Mức độ: Middle.

Smoke kiểm tra build có đủ ổn định để tiếp tục; sanity thường là kiểm tra hẹp sau thay đổi; retest xác nhận fix; regression tìm ảnh hưởng ngoài lỗi vừa sửa.

17. Làm sao xác định test oracle khi đặc tả mơ hồ?#!

Mức độ: Senior.

Đối chiếu rule được xác nhận, invariant, dữ liệu nguồn và hành vi sản phẩm đã thống nhất. Ghi giả định rồi làm rõ với Product/BA.

18. Exploratory testing có thể có cấu trúc không?#!

Mức độ: Middle.

Có: xác định charter, giới hạn thời gian, dữ liệu, vùng rủi ro; ghi các nhánh đã thử, phát hiện và câu hỏi còn mở.

19. Coverage nên đo thế nào ngoài số lượng test case?#!

Mức độ: Senior.

Theo requirement, risk, role, state transition, platform và loại lỗi quan trọng. Liên kết test với rủi ro, theo dõi vùng chưa có oracle hoặc evidence.

20. Khi nào dừng kiểm thử và đề xuất release?#!

Mức độ: Senior.

Khi đạt exit criteria đã thống nhất, rủi ro tồn dư được mô tả và người có thẩm quyền chấp nhận. Đánh giá cả rollback, monitoring và khả năng phát hiện sự cố.

3. SSO, SAML và quản lý phiên#

21. SSO, federation và Identity Provider liên quan thế nào?#!

Mức độ: Middle.

SSO cho phép dùng phiên xác thực để vào nhiều ứng dụng; federation thiết lập niềm tin giữa hệ thống; IdP xác thực và cung cấp thông tin danh tính cho ứng dụng tin cậy.

22. Bạn thiết kế test SSO cho hai ứng dụng thế nào?#!

Mức độ: Middle.

Kiểm tra login A rồi mở B, chưa login, session hết hạn, đổi tài khoản, nhiều tab, logout và user không có quyền ở B.

23. SAML khác OIDC ở góc nhìn QC như thế nào?#!

Mức độ: Senior.

SAML thường trao đổi XML assertion qua browser; OIDC dùng các endpoint OAuth và ID token. QC kiểm tra trust, audience, thời hạn, correlation và mapping ở cả hai.

24. Bạn kiểm tra một SAML assertion thế nào?#!

Mức độ: Senior.

Kiểm tra chữ ký bằng khóa tin cậy, issuer, audience, recipient, thời hạn và liên hệ request khi áp dụng. Thử replay, sai audience và nội dung bị sửa.

25. SP-initiated và IdP-initiated SSO có khác biệt gì?#!

Mức độ: Senior.

SP-initiated bắt đầu từ ứng dụng có request để đối chiếu response; IdP-initiated bắt đầu từ IdP và có thể không có request tương ứng.

26. Bạn kiểm thử Single Logout như thế nào?#!

Mức độ: Senior.

Xác định logout local hay toàn hệ thống, các app tham gia và cơ chế thông báo. Kiểm tra session cookie, refresh token, app đang mở và app không online.

27. User bị khóa tại IdP nhưng app vẫn hoạt động: có phải lỗi?#!

Mức độ: Senior.

So sánh với cam kết thu hồi quyền và kiến trúc session/token. Có thể app giữ session hoặc JWT chưa hết hạn; cần đo cửa sổ truy cập và kiểm tra cơ chế đồng bộ.

28. Bạn kiểm thử timeout và remember me thế nào?#!

Mức độ: Middle.

Tách idle timeout, absolute timeout, thời hạn token và phiên IdP. Kiểm tra sát mốc, hoạt động nền, đóng/mở browser và thiết bị dùng chung.

29. SSO redirect loop được điều tra thế nào?#!

Mức độ: Senior.

Ghi redirect chain, cookie domain/path/SameSite/Secure, callback URI và session của IdP/app. Kiểm tra proxy scheme và mapping tenant.

30. Account linking bằng email có rủi ro gì?#!

Mức độ: Senior.

Không tự hợp nhất tài khoản chỉ vì email trùng. Kiểm tra issuer/subject, email đã xác minh, quyền kiểm soát tài khoản hiện hữu và chính sách liên kết.

31. Bạn kiểm thử MFA và step-up authentication thế nào?#!

Mức độ: Senior.

Kiểm tra đăng ký, challenge, recovery, mất thiết bị và yêu cầu xác thực mạnh hơn trước thao tác nhạy cảm. Xác nhận backend thực thi yêu cầu.

32. Nếu IdP gặp sự cố, bạn kiểm thử phương án dự phòng thế nào?#!

Mức độ: Senior.

Phân biệt login mới, session hiện hữu và tác vụ đang chạy; đánh giá fail-closed theo chính sách. Break-glass nếu có phải giới hạn quyền, được audit và kiểm thử riêng.

4. OAuth 2.0, OpenID Connect và token security#

33. OAuth 2.0 có phải giao thức đăng nhập không?#!

Mức độ: Middle.

OAuth 2.0 phục vụ delegated authorization; OIDC bổ sung lớp xác thực. Với login, kiểm tra OIDC flow và ID token thay vì coi mọi access token là bằng chứng danh tính.

34. Mô tả Authorization Code Flow với PKCE.#!

Mức độ: Middle.

Client tạo verifier/challenge, gửi authorization request; nhận code ở callback rồi đổi code cùng verifier tại token endpoint. Server đối chiếu challenge trước khi cấp token.

35. Bạn kiểm thử PKCE ngoài happy path thế nào?#!

Mức độ: Senior.

Thử verifier thuộc phiên khác, challenge bị thay, thiếu challenge và downgrade method. Chọn S256; xác minh server thực thi binding chứ không chỉ nhận tham số.

36. State, nonce và PKCE khác nhau thế nào?#!

Mức độ: Senior.

State thường liên kết callback với phiên yêu cầu và chống login CSRF; nonce liên kết ID token với giao dịch OIDC; PKCE bảo vệ việc đổi code.

37. Access token, ID token và refresh token dùng ở đâu?#!

Mức độ: Middle.

Access token truy cập resource server; ID token phục vụ client xác minh phiên đăng nhập; refresh token dùng tại authorization server để xin token mới.

38. Bạn validate JWT thế nào?#!

Mức độ: Senior.

Kiểm tra chữ ký với khóa tin cậy, thuật toán cho phép, issuer, audience, thời hạn và claim bắt buộc theo loại token. Decode payload không tương đương validation.

39. Bạn kiểm thử JWKS rotation thế nào?#!

Mức độ: Senior.

Kiểm tra khóa cũ/mới trong giai đoạn chuyển tiếp, kid lạ, cache hết hạn và endpoint JWKS lỗi. Token hợp lệ cần hoạt động theo chính sách rotation, token giả phải bị từ chối.

40. Refresh token rotation có những failure mode nào?#!

Mức độ: Senior.

Kiểm tra token cũ sau khi đổi, replay, token family và hai request refresh đồng thời. Chính sách phải phân biệt retry hợp lệ với reuse đáng ngờ theo thiết kế.

41. Revocation endpoint trả 200 có chứng minh token đã bị thu hồi không?#!

Mức độ: Senior.

Không. Endpoint có thể trả thành công cả khi token không còn hợp lệ. Phải gọi lại resource và refresh endpoint để xác nhận tác động thực tế.

42. Opaque token và JWT ảnh hưởng chiến lược test thế nào?#!

Mức độ: Senior.

Opaque token thường được kiểm tra qua state/introspection; JWT có thể được validate cục bộ. Kiểm thử thêm cache, thu hồi quyền, outage và latency tùy kiến trúc.

43. Bạn kiểm thử redirect URI thế nào?#!

Mức độ: Senior.

Dùng allowlist đăng ký chính xác; thử sai scheme, host, port, path, query và open redirect. Native loopback có ngoại lệ port theo chuẩn liên quan.

44. Public client khác confidential client thế nào?#!

Mức độ: Middle.

Public client không giữ bí mật client một cách đáng tin cậy, như mobile/SPA; confidential client có môi trường bảo vệ credential, thường phía server.

45. Client Credentials Flow có phù hợp cho người dùng đăng nhập không?#!

Mức độ: Senior.

Không; nó phục vụ client truy cập bằng danh tính của chính client, thường machine-to-machine. Kiểm tra scope, audience và quyền service account.

46. Scope, audience và role khác nhau thế nào?#!

Mức độ: Senior.

Scope mô tả quyền được cấp trong giao thức; audience xác định nơi nhận token; role thuộc mô hình phân quyền ứng dụng. Quyết định cuối còn phụ thuộc resource và policy.

47. Implicit và password grant có nên dùng cho thiết kế mới không?#!

Mức độ: Senior.

Không chọn làm mặc định. Security BCP loại bỏ password grant và khuyến cáo tránh cách trả access token qua authorization response; ưu tiên code flow được bảo vệ phù hợp.

48. OAuth trên mobile cần kiểm thử điểm gì riêng?#!

Mức độ: Senior.

Dùng browser/system authentication session phù hợp, kiểm tra callback/deep link, app background/killed, nhiều app xử lý URL và bảo vệ token trên thiết bị.

49. Bearer token và DPoP khác nhau thế nào?#!

Mức độ: Senior.

Bearer token có thể dùng bởi bên nắm token; DPoP ràng buộc token với khóa và proof cho request. Kiểm tra proof, method/URI, thời gian và replay theo chuẩn.

50. Bạn đánh giá cookie session, localStorage và BFF thế nào?#!

Mức độ: Senior.

So sánh rủi ro XSS, CSRF, token exposure và độ phức tạp vận hành. BFF có thể giữ token phía server; cookie cần thuộc tính và bảo vệ CSRF phù hợp.

5. IAM, authorization và vòng đời danh tính#

51. IAM bao gồm những gì ngoài login?#!

Mức độ: Middle.

Quản lý danh tính, cấp/thu hồi quyền, policy, service account, vòng đời nhân sự và audit. Authentication chỉ là một phần.

52. RBAC và ABAC khác nhau thế nào?#!

Mức độ: Middle.

RBAC cấp quyền qua role; ABAC xét thuộc tính của actor, resource và ngữ cảnh. Có thể kết hợp hai mô hình.

53. Thiết kế permission matrix cho storage thế nào?#!

Mức độ: Senior.

Liệt kê actor, action, resource, tenant, ownership và trạng thái chia sẻ; xác định allow/deny cho từng tổ hợp quan trọng.

54. Phân biệt horizontal và vertical privilege escalation.#!

Mức độ: Senior.

Horizontal là truy cập dữ liệu của chủ thể ngang quyền; vertical là thực hiện quyền cao hơn. Cần kiểm tra cả ownership lẫn chức năng.

55. Bạn kiểm thử tenant isolation trên những lớp nào?#!

Mức độ: Senior.

API, DB query, object storage, search index, cache, queue, export, log và AI retrieval. Tenant context phải được xác định và kiểm tra ở ranh giới tin cậy.

56. Deny by default có nghĩa gì trong kiểm thử?#!

Mức độ: Senior.

Trường hợp chưa có rule allow hợp lệ phải bị từ chối. Kiểm tra role mới, action mới, claim thiếu và policy lookup lỗi.

57. Bạn kiểm thử thay đổi role khi user đang online thế nào?#!

Mức độ: Senior.

Đổi role, dùng token/session cũ gọi lại API, thử refresh, nhiều tab và background job. Đo thời gian cập nhật quyền theo cam kết.

58. SCIM giải quyết bài toán gì và cần test gì?#!

Mức độ: Senior.

SCIM chuẩn hóa quản lý tài nguyên danh tính như user/group giữa hệ thống. Kiểm tra create/update/deactivate, mapping, retry và đồng bộ một phần.

59. Just-in-time provisioning có rủi ro gì?#!

Mức độ: Senior.

Tài khoản được tạo khi login có thể nhận sai tenant, role mặc định quá rộng hoặc trùng identity. Cần kiểm tra mapping và luồng không được phép tự gia nhập.

60. Bạn kiểm thử offboarding hoàn chỉnh thế nào?#!

Mức độ: Senior.

Khóa identity, thu hồi membership/session/token, xử lý thiết bị và quyền chia sẻ; kiểm tra scheduled job, API key và dữ liệu đã giao cho người nhận.

61. TOCTOU trong authorization là gì?#!

Mức độ: Senior.

Quyền được kiểm tra ở một thời điểm nhưng resource hoặc policy thay đổi trước lúc hành động hoàn tất. Cần kiểm tra quyết định tại điểm nhạy cảm.

62. Service account cần kiểm thử gì?#!

Mức độ: Middle.

Quyền tối thiểu, scope/tenant, credential rotation, hết hạn, thu hồi và audit riêng. Tách tài khoản người dùng khỏi workload identity.

63. Audit log tốt cho IAM cần những thông tin nào?#!

Mức độ: Senior.

Actor, action, target, tenant, thời gian, kết quả, lý do và correlation ID; bảo vệ khỏi sửa/xóa trái phép, tránh ghi token hoặc khóa bí mật.

64. Temporary access và quyền kế thừa cần test thế nào?#!

Mức độ: Senior.

Kiểm tra thời hạn, timezone, group lồng nhau, nhiều nguồn cấp quyền và độ ưu tiên allow/deny theo policy.

65. Bạn kiểm thử bulk import user/group thế nào?#!

Mức độ: Senior.

Kiểm tra duplicate, mapping sai tenant, partial failure, validation từng dòng, retry và rollback theo contract.

66. Bạn thiết kế regression authorization có khả năng mở rộng thế nào?#!

Mức độ: Lead.

Sinh case từ policy matrix, chạy API tests nhanh theo role/tenant, giữ một số E2E cho mapping UI/session và thêm case khi endpoint hoặc policy đổi.

6. E2EE và kiểm thử encrypted storage#

67. E2EE khác TLS và encryption at rest thế nào?#!

Mức độ: Middle.

TLS bảo vệ đường truyền; encryption at rest bảo vệ dữ liệu lưu trữ; E2EE giữ nội dung chỉ giải mã được tại các endpoint được tin cậy trong mô hình thiết kế.

68. Bạn bắt đầu test strategy E2EE bằng câu hỏi nào?#!

Mức độ: Senior.

Hỏi dữ liệu nào được mã hóa, endpoint nào đáng tin, ai giữ khóa, server có thể độc hại không, và recovery/sharing hoạt động thế nào.

69. Symmetric encryption, asymmetric encryption, hash và chữ ký khác nhau thế nào?#!

Mức độ: Middle.

Mã hóa đối xứng dùng khóa bí mật chung; bất đối xứng dùng cặp khóa; hash tạo digest; chữ ký hỗ trợ xác minh nguồn và tính toàn vẹn.

70. DEK, KEK và envelope encryption là gì?#!

Mức độ: Senior.

DEK mã hóa dữ liệu; KEK bảo vệ DEK. Envelope encryption giúp quản lý và thay lớp khóa bảo vệ mà không luôn phải mã hóa lại toàn bộ dữ liệu.

71. Bạn kiểm tra server không nhận plaintext bằng cách nào?#!

Mức độ: Senior.

Dùng nội dung canary giả, quan sát request, storage, DB, log, telemetry, preview và backup; kết hợp review luồng khóa và kiến trúc.

72. AEAD bảo vệ gì và cần negative test nào?#!

Mức độ: Senior.

AEAD bảo vệ bí mật cùng tính toàn vẹn/xác thực dữ liệu dưới khóa; thử đổi ciphertext, tag, nonce hoặc associated data để kiểm tra giải mã thất bại.

73. Vì sao nonce reuse nguy hiểm?#!

Mức độ: Senior.

Nhiều AEAD như AES-GCM yêu cầu nonce không lặp dưới cùng khóa; vi phạm có thể phá bí mật và toàn vẹn. Kiểm tra thiết kế sinh nonce qua retry, restart và song song.

74. Chunked encryption của file lớn cần kiểm thử gì?#!

Mức độ: Senior.

Thử mất chunk, lặp, đảo thứ tự, tráo giữa file, cắt ngắn và resume. Metadata xác thực cần ràng buộc thứ tự, file/version và tính đầy đủ theo protocol.

75. Upload/download E2EE thành công cần assert gì?#!

Mức độ: Middle.

Client nhận lại đúng nội dung, kích thước và metadata mong đợi; ciphertext được lưu đúng; user không có quyền không lấy được vật liệu giải mã.

76. Bạn kiểm thử chia sẻ file E2EE thế nào?#!

Mức độ: Senior.

Xác minh đúng recipient nhận khả năng giải mã, outsider không nhận, thay quyền có hiệu lực theo contract và wrapped key gắn đúng file/version/user.

77. Thu hồi quyền E2EE có xóa khả năng đọc mọi dữ liệu cũ không?#!

Mức độ: Senior.

Không thể bảo đảm nếu người nhận đã lưu plaintext hoặc khóa cùng ciphertext. Có thể chặn tải mới, thu hồi envelope và thay khóa cho nội dung tương lai theo thiết kế.

78. Reset password và account recovery ảnh hưởng E2EE thế nào?#!

Mức độ: Senior.

Phụ thuộc cách khóa được bảo vệ: recovery key, thiết bị tin cậy hoặc escrow được thiết kế trước. Reset mật khẩu đăng nhập không tự khôi phục khóa giải mã đã mất.

79. Thêm và xóa thiết bị trong hệ thống E2EE cần test gì?#!

Mức độ: Senior.

Xác minh thiết bị mới được ủy quyền, nhận đúng khóa và thiết bị bị xóa không nhận khóa/dữ liệu mới theo policy. Kiểm tra enrollment giả và sync bị gián đoạn.

80. Public key substitution là gì và QC kiểm tra thế nào?#!

Mức độ: Senior.

Server hoặc bên trung gian thay public key người nhận khiến dữ liệu được chia sẻ cho khóa khác. Kiểm tra cơ chế xác minh identity–key, cảnh báo thay khóa hoặc transparency nếu có.

81. Key rotation khác re-encryption thế nào?#!

Mức độ: Senior.

Rotation thay khóa hoặc version sử dụng; re-encryption mã hóa lại dữ liệu. Đổi KEK có thể chỉ rewrap DEK, còn DEK bị lộ có thể cần xử lý dữ liệu và phiên bản liên quan.

82. Backup/restore E2EE cần bảo đảm điều gì?#!

Mức độ: Senior.

Khôi phục đồng bộ ciphertext, key envelope, version, quyền và metadata cần thiết; dữ liệu khôi phục phải giải mã được bởi đúng chủ thể.

83. Metadata nào vẫn có thể lộ dù nội dung E2EE?#!

Mức độ: Senior.

Tùy thiết kế: kích thước, thời điểm, tên file, người tham gia, IP và mẫu truy cập. Cần liệt kê phần được bảo vệ và phần còn quan sát được.

84. Search, preview và antivirus hoạt động thế nào khi storage E2EE?#!

Mức độ: Senior.

Cần thiết kế phù hợp như xử lý phía client hoặc cơ chế chia sẻ dữ liệu có chủ đích. Server không thể tùy ý phân tích plaintext mà vẫn giữ cùng cam kết không thấy nội dung.

85. E2EE có tự có forward secrecy và bảo vệ thiết bị bị chiếm không?#!

Mức độ: Senior.

Không. Forward secrecy phụ thuộc protocol và vòng đời khóa; endpoint bị chiếm có thể lộ plaintext hoặc khóa. E2EE không thay bảo vệ thiết bị.

86. Bạn đặt release gate nào cho encrypted storage?#!

Mức độ: Lead.

Chặn mất dữ liệu, giải mã sai không phát hiện, lộ plaintext/khóa và truy cập sai chủ thể. Yêu cầu evidence cho recovery, sharing, revoke, migration và client compatibility.

7. Tình huống kết hợp SSO, OAuth, IAM và E2EE#

87. Nhân viên nghỉ việc đang giữ phiên và file offline: bạn test thế nào?#!

Mức độ: Senior.

Tạo ma trận login mới, token cũ, refresh, download, key fetch, offline ciphertext và plaintext đã tải. Đặt expected riêng theo policy từng trạng thái.

88. User đổi phòng ban nhưng vẫn giữ link chia sẻ cũ thì sao?#!

Mức độ: Senior.

Kiểm tra membership mới/cũ, grant trực tiếp, grant qua group, cached permission và key envelope. Xác định nguồn quyền còn hiệu lực trước khi kết luận.

89. Hai tenant dùng cùng email có thể đọc nhầm vault không?#!

Mức độ: Senior.

Không được nếu policy cô lập tenant. Kiểm tra identity mapping, account linking, token issuer/audience, tenant context và danh tính sở hữu khóa.

90. Access token hết hạn khi upload file mã hóa thì xử lý thế nào?#!

Mức độ: Senior.

Xác định cơ chế refresh/resume, authorization tại finalize và tuổi thọ upload URL. Không tạo bản trùng hoặc mất khả năng giải mã khi request được thử lại.

91. Admin reset tài khoản có nên đọc được file E2EE không?#!

Mức độ: Senior.

Chỉ nếu mô hình recovery/escrow đã công bố cho phép. Quyền quản trị IAM không tự đồng nghĩa quyền giải mã nội dung.

92. JWT còn hạn nhưng quyền chia sẻ đã bị xóa: API nên làm gì?#!

Mức độ: Senior.

Thực thi policy hiện hành hoặc cửa sổ hiệu lực được định nghĩa; token còn hạn chỉ chứng minh credential chưa hết hạn, không bảo đảm entitlement còn tồn tại.

93. Chatbot doanh nghiệp truy vấn kho E2EE cần kiểm thử gì?#!

Mức độ: Senior.

Làm rõ nơi giải mã và phạm vi nội dung được đưa cho model. Kiểm tra consent, quyền retrieval, tenant isolation, log và khả năng thu hồi dữ liệu/index.

94. Thiết kế một E2E acceptance flow cho toàn bộ hệ thống.#!

Mức độ: Lead.

Provision user → SSO → upload mã hóa → chia sẻ đúng người → kiểm tra outsider → đổi quyền → revoke → recovery có kiểm soát → audit.

8. Automation framework, Playwright, Cypress và mobile#

95. Bạn thiết kế framework automation từ đầu thế nào?#!

Mức độ: Senior.

Bắt đầu từ rủi ro và feedback cần có; chia test, domain helpers, API clients, fixtures, config và reporting. Chọn ít abstraction nhưng rõ trách nhiệm.

96. Page Object Model giúp gì và có giới hạn gì?#!

Mức độ: Middle.

Đóng gói tương tác giao diện và locator để giảm lặp; không giấu toàn bộ nghiệp vụ vào một lớp khổng lồ hoặc dùng inheritance khó theo dõi.

97. Bạn chọn locator Playwright thế nào?#!

Mức độ: Middle.

Ưu tiên role/accessible name hoặc test ID ổn định; scope vào vùng đúng và tránh selector phụ thuộc thứ tự DOM khi không cần.

98. Auto-wait có loại bỏ mọi flaky test không?#!

Mức độ: Senior.

Không. Nó giúp chờ điều kiện thao tác và assertion phù hợp, nhưng không tự biết nghiệp vụ async đã hoàn tất hoặc dữ liệu backend đã hội tụ.

99. Fixtures và test isolation nên tổ chức thế nào?#!

Mức độ: Senior.

Mỗi test có dữ liệu riêng; tài nguyên đắt có thể theo worker nếu không gây xung đột. Setup/teardown rõ và không phụ thuộc thứ tự test.

100. Dùng storageState có còn kiểm thử được login không?#!

Mức độ: Senior.

StorageState giúp test nghiệp vụ bắt đầu từ phiên đã xác thực; cần suite riêng kiểm tra login thật, expiry, logout và session.

101. Bạn automate SSO qua IdP bên ngoài ra sao?#!

Mức độ: Senior.

Dùng test tenant/account được quản lý, giữ số E2E login thật vừa đủ; phần lớn policy/session case có thể dùng môi trường IdP test có kiểm soát.

102. Khi nào dùng mock, stub và service virtualization?#!

Mức độ: Senior.

Khi cần phản hồi hiếm, lỗi dependency hoặc tính xác định ở test cấp thấp; vẫn giữ kiểm tra tích hợp thật cho ranh giới quan trọng.

103. Bạn xử lý flaky test như thế nào?#!

Mức độ: Senior.

Thu trace, network, dữ liệu và lịch chạy; phân loại race sản phẩm, test timing, dữ liệu chung, môi trường hoặc dependency. Sửa nguyên nhân rồi theo dõi tái phát.

104. Chạy song song và sharding có những rủi ro gì?#!

Mức độ: Senior.

Đụng dữ liệu, session dùng chung, quota, thứ tự teardown và quá tải backend. Chia tải theo tài nguyên thực tế, không chỉ tăng worker.

105. Selenium implicit wait và explicit wait khác nhau thế nào?#!

Mức độ: Middle.

Implicit wait áp dụng tìm element; explicit wait chờ điều kiện cụ thể. Tránh trộn tùy tiện vì có thể tạo thời gian chờ khó đoán.

106. So sánh Cypress và Playwright khi kiểm thử SSO.#!

Mức độ: Senior.

Đánh giá flow nhiều origin/tab, cách thực thi, network control, debug, CI và kỹ năng đội. Cypress hỗ trợ thao tác cross-origin qua cơ chế như cy.origin theo điều kiện của nó.

107. Appium và Detox khác nhau ở điểm nào?#!

Mức độ: Middle.

Appium điều khiển qua driver/platform automation; Detox có cơ chế đồng bộ với ứng dụng được tích hợp hỗ trợ, thường dùng trong hệ sinh thái React Native.

108. Detox bị chờ mãi vì app không idle thì xử lý thế nào?#!

Mức độ: Senior.

Kiểm tra tài nguyên đang giữ busy như network, timer hoặc animation; tìm nguyên nhân và cấu hình đồng bộ có phạm vi khi cần.

109. Mobile regression cần những điều kiện ngoài kích thước màn hình?#!

Mức độ: Senior.

OS, permission, app lifecycle, mạng chập chờn, offline, push/deep link, keyboard, storage và nâng cấp app.

110. Bạn chọn test nào nên tự động hóa trước?#!

Mức độ: Lead.

Chọn luồng rủi ro cao, lặp thường xuyên, expected rõ và dữ liệu kiểm soát được; tính cả chi phí duy trì, thời gian chạy và khả năng debug.

9. API testing, contract và hệ thống phân tán#

111. Một API test tốt cần kiểm tra gì ngoài status code?#!

Mức độ: Middle.

Schema, giá trị nghiệp vụ, headers, quyền truy cập, side effect và dữ liệu lưu. Với lỗi, xác minh không tạo thay đổi ngoài ý muốn.

112. Thiết kế test idempotency cho create order thế nào?#!

Mức độ: Senior.

Gửi lại cùng key/payload, đồng thời cùng key, cùng key khác payload và retry sau timeout. Kỳ vọng số side effect theo contract, thường một thao tác nghiệp vụ.

113. Timeout khác giao dịch thất bại thế nào?#!

Mức độ: Senior.

Timeout là client không nhận kết quả đúng hạn; server có thể đã commit. Cần truy vấn trạng thái hoặc retry idempotent trước khi tạo thao tác mới.

114. Bạn kiểm thử webhook thế nào?#!

Mức độ: Senior.

Xác minh chữ ký theo provider contract, timestamp, replay, duplicate, sai thứ tự và retry. Kiểm tra acknowledgment và side effect idempotent.

115. 401, 403 và 404 khác nhau trong test quyền thế nào?#!

Mức độ: Middle.

401 liên quan thiếu/không hợp lệ authentication; 403 là từ chối quyền; 404 có thể dùng để không tiết lộ resource theo contract.

116. Pagination, filtering và sorting có thể gây lỗi bảo mật gì?#!

Mức độ: Senior.

Filter bị bỏ qua, tenant bị trộn, cursor dùng lại sai user hoặc response count làm lộ tài nguyên. Kiểm tra cả dữ liệu và metadata.

117. Contract testing bổ sung gì cho E2E?#!

Mức độ: Senior.

Phát hiện thay đổi cấu trúc/ý nghĩa API giữa consumer và provider sớm hơn; E2E xác nhận luồng tích hợp với cấu hình và dữ liệu thật.

118. Postman collection nên tổ chức thế nào để chạy được trong pipeline?#!

Mức độ: Middle.

Tách environment, credential và dữ liệu; viết assertion có ý nghĩa; tránh phụ thuộc request order không rõ và xuất báo cáo máy đọc được.

119. Rest Assured khác OkHttp thế nào?#!

Mức độ: Senior.

Rest Assured cung cấp DSL phục vụ kiểm thử REST trong Java; OkHttp là HTTP client, cần ghép test runner/assertion để thành bộ kiểm thử.

120. Eventual consistency và retry nên được test thế nào?#!

Mức độ: Senior.

Xác định dữ liệu nguồn, thời gian hội tụ và trạng thái trung gian được phép. Poll có deadline/backoff; retry thao tác ghi phải xét idempotency.

10. SQL, PostgreSQL, MongoDB và kiểm chứng dữ liệu#

121. Bạn kiểm tra UI–API–DB consistency ra sao?#!

Mức độ: Middle.

Chọn source of truth và thời điểm so sánh; đối chiếu ID, số lượng, tiền, trạng thái và timezone qua từng lớp.

122. INNER JOIN và LEFT JOIN khác nhau trong tìm dữ liệu lỗi thế nào?#!

Mức độ: Middle.

INNER JOIN chỉ giữ bản ghi khớp; LEFT JOIN giữ cả bản ghi bên trái thiếu đối ứng. Dùng LEFT JOIN cùng điều kiện NULL để tìm orphan khi phù hợp.

123. Làm sao tìm giao dịch bị duplicate bằng SQL?#!

Mức độ: Senior.

GROUP BY khóa nghiệp vụ đúng phạm vi, dùng HAVING COUNT(*) > 1 rồi xem chi tiết. Phân biệt duplicate với nhiều payment attempt hợp lệ.

124. Transaction isolation ảnh hưởng test concurrency thế nào?#!

Mức độ: Senior.

Các mức isolation cho phép những quan sát đồng thời khác nhau; cần biết database và mức cấu hình thật. Dùng hai connection với barrier để tái hiện.

125. Kiểm thử rollback và saga khác nhau thế nào?#!

Mức độ: Senior.

Transaction rollback hoàn tác trong phạm vi atomic của database; saga dùng compensation qua nhiều dịch vụ và có thể có trạng thái trung gian.

126. MongoDB read/write concern ảnh hưởng kết luận kiểm thử thế nào?#!

Mức độ: Middle.

Chúng ảnh hưởng acknowledgment, tính bền vững và dữ liệu có thể đọc trong bối cảnh replica. Cần biết topology và cấu hình thực.

127. Bạn kiểm thử migration dữ liệu lịch sử thế nào?#!

Mức độ: Senior.

Tạo dữ liệu nhiều version, nullable/legacy value, kiểm tra mapping, số lượng, invariant và khả năng tương thích trong rollout.

128. Làm sao đối soát số tiền và tránh lỗi rounding?#!

Mức độ: Senior.

Dùng quy tắc tiền tệ, precision và thứ tự làm tròn đã thống nhất; so sánh tổng dòng hàng, thuế, discount, thanh toán và refund.

11. Performance testing với JMeter và k6#

129. Load, stress, spike và soak test khác nhau thế nào?#!

Mức độ: Middle.

Load đánh giá tải dự kiến; stress tìm giới hạn và cách suy giảm; spike thử biến động đột ngột; soak quan sát vấn đề tích lũy theo thời gian.

130. Bạn xây workload sát thực tế thế nào?#!

Mức độ: Senior.

Dựa trên traffic, tỷ lệ thao tác, kích thước dữ liệu, think time, concurrency và phân bố tenant. Khi chưa có số liệu, ghi rõ giả định.

131. P95, P99, throughput và error rate nói gì?#!

Mức độ: Middle.

Percentile mô tả phân bố latency; throughput là lượng công việc hoàn thành theo thời gian; error rate cần định nghĩa theo lỗi kỹ thuật và nghiệp vụ.

132. Closed model và open model ảnh hưởng kết quả ra sao?#!

Mức độ: Senior.

Closed model giới hạn số user lặp; open model đưa request theo arrival rate. Khi hệ thống chậm, closed model có thể giảm lượng request phát ra.

133. JMeter chạy local nhanh nhưng CI chậm: bạn điều tra gì?#!

Mức độ: Senior.

CPU/RAM/network của load generator, listener/logging, dữ liệu và môi trường đích. Chạy load bằng CLI phù hợp, theo dõi cả máy phát tải.

134. Check và threshold trong k6 khác nhau thế nào?#!

Mức độ: Senior.

Check ghi kết quả điều kiện; threshold đặt tiêu chí pass/fail của test trên metric. Muốn pipeline chặn theo check cần threshold hoặc cơ chế gate tương ứng.

135. Bạn phân tích bottleneck order/promotion thế nào?#!

Mức độ: Senior.

Đối chiếu latency với trace, query, lock, CPU, connection pool và dependency. Thay một yếu tố để kiểm chứng giả thuyết.

136. Đo hiệu năng E2EE phải tách những thành phần nào?#!

Mức độ: Senior.

Tách sinh/unwrap khóa, mã hóa/giải mã client, network, storage và commit metadata. Đo CPU/RAM/pin trên thiết bị cùng latency backend.

12. Git, GitLab/Jenkins, CI/CD và defect management#

137. Bạn dùng Git trong công việc QC thế nào?#!

Mức độ: Middle.

Đọc diff để xác định vùng ảnh hưởng, quản lý test theo branch, review thay đổi và gắn kết quả với commit/build cụ thể.

138. Bạn tổ chức pipeline automation thế nào?#!

Mức độ: Senior.

Chạy checks nhanh và API tests sớm, smoke khi deploy môi trường, E2E/security regression theo rủi ro; lịch riêng cho load/soak khi phù hợp.

139. JUnit report có tự làm GitLab pipeline thất bại không?#!

Mức độ: Senior.

Không; report phục vụ hiển thị kết quả. Job phải trả exit status đúng và cấu hình gate không được bỏ qua lỗi ngoài chủ đích.

140. Quản lý secrets và artifacts trong CI ra sao?#!

Mức độ: Senior.

Dùng secret store/biến bảo vệ, tài khoản test ít quyền, redaction và retention phù hợp. Không đưa token, storageState hoặc khóa E2EE vào artifact không kiểm soát.

141. GitLab và Jenkins khác nhau ở góc độ triển khai test thế nào?#!

Mức độ: Senior.

Cùng cần checkout, environment, runner/agent, script, secrets và report; khác mô hình cấu hình, plugin và cách tích hợp. Chuyển nguyên tắc trước, xác minh cú pháp sau.

142. Bug report tốt cần những gì?#!

Mức độ: Middle.

Build/môi trường, tiền điều kiện, bước tái hiện, expected/actual, tác động và evidence đủ để điều tra. Che thông tin nhạy cảm.

143. Severity và priority khác nhau thế nào?#!

Mức độ: Senior.

Severity phản ánh mức ảnh hưởng; priority phản ánh thứ tự xử lý trong bối cảnh kinh doanh, exposure và nguồn lực. Đội cần thống nhất tiêu chí.

144. Bạn xác minh hotfix production thế nào?#!

Mức độ: Senior.

Xác nhận build, case tái hiện, vùng ảnh hưởng và tín hiệu vận hành; dùng dữ liệu/tài khoản kiểm thử được phép, theo dõi rollout và rollback.

13. AI-assisted testing, harness và kiểm chứng đầu ra#

145. Harness engineering trong workflow QC nghĩa là gì?#!

Mức độ: Middle.

Thiết kế môi trường, context, tool, dữ liệu, giới hạn và cơ chế đánh giá để AI thực hiện tác vụ kiểm thử có thể lặp lại và kiểm chứng.

146. Spec-driven test automation với AI nên triển khai thế nào?#!

Mức độ: Senior.

Chốt acceptance criteria, risk và examples; sinh scenario rồi review; tạo automation, chạy trên hệ thống và đối chiếu coverage với spec.

147. Bạn cung cấp context gì để AI sinh test hữu ích?#!

Mức độ: Senior.

Luồng nghiệp vụ, policy, schema, ví dụ hợp lệ/không hợp lệ, constraint môi trường và format đầu ra. Dữ liệu phải phù hợp quyền sử dụng.

148. Làm sao phát hiện test do AI sinh bị sai?#!

Mức độ: Senior.

Review oracle, locator, dữ liệu, assertions và cleanup; chạy với biến thể lỗi có chủ đích để xem test có thực sự phát hiện.

149. Self-healing locator có thể gây pass giả thế nào?#!

Mức độ: Senior.

Tool có thể chọn phần tử tương tự nhưng sai ý nghĩa, khiến test đi nhầm luồng. Mọi thay đổi locator cần evidence và assertion nghiệp vụ bảo vệ.

150. AI agent điều khiển browser khác script xác định ra sao?#!

Mức độ: Senior.

Agent diễn giải tình huống và chọn hành động động; script có luồng/assertion rõ hơn. Agent hữu ích cho exploration, nhưng regression cần khả năng tái lập và oracle đáng tin.

151. MCP mang lại gì và có rủi ro gì trong test workflow?#!

Mức độ: Senior.

MCP giúp kết nối ứng dụng AI với tool/context qua giao thức chung. Cần kiểm soát quyền tool, tài nguyên đích và dữ liệu trả về.

152. Prompt injection có thể xuất hiện trong lúc AI test sản phẩm không?#!

Mức độ: Senior.

Có, qua trang web, file, ticket hoặc log mà agent đọc. Nội dung đó có thể dụ agent đổi mục tiêu, tiết lộ dữ liệu hoặc dùng tool sai.

153. Bạn đo chất lượng công cụ AI phát hiện defect thế nào?#!

Mức độ: Senior.

Đo precision, recall trên bộ lỗi có nhãn phù hợp, thời gian review, lỗi nghiêm trọng bỏ sót và chi phí tổng. Tách theo loại lỗi.

154. Bạn đưa AI vào đội QC theo lộ trình nào?#!

Mức độ: Lead.

Bắt đầu tác vụ dễ review như gợi ý scenario và tóm tắt defect; pilot có baseline, giới hạn dữ liệu/quyền, đo kết quả rồi mở rộng.

14. AI chatbot doanh nghiệp và đánh giá chất lượng#

155. Test chatbot khác test API xác định thế nào?#!

Mức độ: Middle.

Kết quả ngôn ngữ có biến thiên; cần rubric, tập câu hỏi và tiêu chí nội dung thay vì so sánh nguyên chuỗi. Các phần quyền và side effect vẫn phải kiểm tra chính xác.

156. Bạn xây golden dataset cho enterprise chatbot thế nào?#!

Mức độ: Senior.

Chọn câu đại diện, dữ liệu nguồn có version, đáp án/rubric được duyệt, câu không có đáp án và case quyền truy cập.

157. Làm sao phân biệt lỗi retrieval và generation trong RAG?#!

Mức độ: Senior.

Kiểm tra tài liệu/chunk được lấy, thứ hạng và quyền; sau đó đánh giá câu trả lời có bám context đúng không.

158. Bạn kiểm thử hallucination và citation thế nào?#!

Mức độ: Senior.

Đặt câu hỏi có/không có bằng chứng, thông tin mâu thuẫn hoặc lỗi thời; kiểm tra mỗi claim quan trọng được nguồn thực hỗ trợ và citation mở đúng tài liệu.

159. Chatbot cần kiểm thử quyền ở retrieval hay output?#!

Mức độ: Senior.

Cả hai, nhưng policy phải chặn truy xuất trái phép trước khi nội dung vào model; lọc output chỉ là lớp bổ sung.

160. Bạn kiểm thử prompt injection trong RAG thế nào?#!

Mức độ: Senior.

Đặt chỉ dẫn độc trong tài liệu giả, câu hỏi người dùng và tool result; kiểm tra model không vượt quyền, tiết lộ dữ liệu hoặc làm hành động trái phạm vi.

161. LLM-as-a-judge có đáng tin để chấm toàn bộ kết quả không?#!

Mức độ: Senior.

Có thể hỗ trợ nhưng cần rubric, calibration với người chấm và kiểm tra bias/độ ổn định. Giữ assertion xác định cho quyền, số tiền và side effect.

162. Bạn regression chatbot sau đổi model hoặc prompt thế nào?#!

Mức độ: Senior.

Cố định corpus/config cần thiết, chạy dataset nhiều nhóm và lặp đủ để quan sát biến thiên; so sánh quality, latency, cost và case nghiêm trọng.

15. CIRCA — POS, promotion, payment, inventory và delivery#

163. Bạn thiết kế test promotion có nhiều điều kiện thế nào?#!

Mức độ: Middle.

Dùng decision table cho thời gian, sản phẩm, số lượng, khách hàng, kênh và thứ tự áp dụng. Lấy expected từ rule đã xác nhận.

164. Voucher giới hạn một lượt dùng cần kiểm tra race thế nào?#!

Mức độ: Senior.

Gửi hai checkout cùng voucher tại barrier đồng thời; kiểm tra reservation, commit, cancel và số lượt dùng cuối.

165. Loyalty points cần những invariant nào?#!

Mức độ: Senior.

Điểm cộng/trừ theo rule, không xử lý lặp event và tổng ledger khớp balance; refund/cancel xử lý đúng phần điểm liên quan.

166. Customer segmentation thay đổi lúc checkout thì expected là gì?#!

Mức độ: Senior.

Xác định thời điểm chốt eligibility: thêm giỏ, checkout hay thanh toán. Kiểm tra thay đổi segment, cache và dữ liệu lịch sử theo rule đó.

167. POS, Admin và online hiển thị khác dữ liệu: bạn xử lý ra sao?#!

Mức độ: Middle.

Đối chiếu nguồn dữ liệu, version, cache, timezone và thời gian đồng bộ. Xác định khác biệt hợp lệ trước khi báo defect.

168. Payment thành công nhưng order pending: bạn kiểm thử thế nào?#!

Mức độ: Senior.

Mô phỏng webhook chậm/mất, lỗi commit và timeout; kiểm tra reconciliation, retry idempotent và trạng thái thông báo cho người dùng.

169. Partial refund có những case quan trọng nào?#!

Mức độ: Senior.

Hoàn một phần số lượng, nhiều lần, discount/tax phân bổ, shipping, loyalty và giới hạn tổng hoàn. Kiểm tra quyền phê duyệt và webhook duplicate.

170. Return và refund có phải cùng một trạng thái không?#!

Mức độ: Senior.

Không. Return liên quan hàng trả; refund liên quan tiền hoàn. Có thể diễn ra lệch thời điểm hoặc không đi kèm theo policy.

171. Bạn kiểm thử inventory reservation và overselling thế nào?#!

Mức độ: Senior.

Kiểm tra giữ hàng, hết hạn, giải phóng sau cancel/payment fail và hai kênh tranh lượng tồn cuối. Đối chiếu available, reserved và sold theo mô hình.

172. Đơn cũ có nên thay đổi khi cập nhật giá/promotion không?#!

Mức độ: Senior.

Thông thường cần giữ snapshot giao dịch theo rule đã chốt; thao tác chỉnh sửa phải có policy và audit riêng. Xác nhận với nghiệp vụ.

173. Delivery integration cần test những failure mode nào?#!

Mức độ: Middle.

Tạo vận đơn trùng, địa chỉ không hợp lệ, provider timeout, callback sai thứ tự, hủy sau pickup và giao một phần.

174. Nếu offline POS được hỗ trợ, bạn test đồng bộ thế nào?#!

Mức độ: Senior.

Làm rõ thao tác offline được phép, nguồn giá/quyền cache, xung đột và chiến lược đồng bộ. Test retry không tạo đơn hoặc trừ tồn trùng.

16. Các dự án HDWebsoft, Connexion và nền tảng web/mobile#

175. Booking App đa tenant cần kiểm tra gì ưu tiên?#!

Mức độ: Senior.

Cô lập lịch và khách hàng, quyền nhân viên, timezone, lịch lặp, cancel/reschedule và tranh cùng slot.

176. Bạn kiểm thử timezone và daylight saving cho booking thế nào?#!

Mức độ: Senior.

Phân biệt instant với giờ địa phương và timezone định danh; thử giờ không tồn tại, giờ lặp, đổi timezone và reminder.

177. Kingmaker Data với bản đồ/data visualization cần oracle gì?#!

Mức độ: Middle.

Đối chiếu dataset nguồn, tọa độ, projection nếu có, filter, aggregation và legend. Kiểm tra null, outlier, dữ liệu lớn và quyền xem.

178. IMP kết nối thiết bị chặn cuộc gọi cần test gì?#!

Mức độ: Senior.

Pairing, reconnect, mất kết nối, permission, firmware/app compatibility và đồng bộ cấu hình. Kiểm tra trạng thái hiển thị so với thiết bị thật.

179. Website builder như Hello Innovation có rủi ro gì?#!

Mức độ: Middle.

Editor, preview, publish, responsive, custom domain và tính toàn vẹn sau save/reload; quyền chỉnh sửa và nội dung không tin cậy.

180. Connexion cần kiểm thử relationship và quyền riêng tư thế nào?#!

Mức độ: Senior.

Kiểm tra invitation, chấp nhận/từ chối, unlink, block, quyền xem note/photo và thay đổi loại quan hệ.

181. Chat/photo trên Android và iOS cần test gì?#!

Mức độ: Senior.

Thứ tự và duplicate message, offline/reconnect, upload interruption, permission, media format, notification và đồng bộ nhiều thiết bị.

182. AWS S3 presigned URL có phải link riêng tư tuyệt đối không?#!

Mức độ: Senior.

URL có quyền tạm thời cho người nắm nó trong phạm vi được ký. Kiểm tra expiry, method/object, quyền credential và khả năng chia sẻ lại.

17. Advertising platform — kiến thức mở rộng theo JD#

183. Impression, click và conversion cần được định nghĩa thế nào trước khi test?#!

Mức độ: Middle.

Chốt sự kiện nào được tính, điều kiện hợp lệ, timestamp và khóa chống trùng. Không tự coi render component là impression có thể tính phí.

184. Attribution cần kiểm tra những tình huống nào?#!

Mức độ: Senior.

Attribution window, click/view-through, nhiều touchpoint, timezone, late event và quy tắc ưu tiên theo sản phẩm.

185. Làm sao test ngân sách quảng cáo không bị vượt do concurrency?#!

Mức độ: Senior.

Gửi nhiều quyết định phân phối/tính phí sát quota, kiểm tra reservation, commit và pacing. Làm rõ độ vượt cho phép nếu có.

186. Click fraud và bot traffic nên được kiểm thử ra sao?#!

Mức độ: Senior.

Dùng traffic tổng hợp có nhãn, đo phát hiện và false positive, kiểm tra rule/model change và tránh tính phí sai.

187. Ad billing cần đối soát những lớp nào?#!

Mức độ: Senior.

Raw events, dedup/filter, aggregation, pricing, ledger và invoice. Kiểm tra currency, rounding, timezone và điều chỉnh sự kiện muộn.

188. Consent và quyền riêng tư ảnh hưởng test tracking thế nào?#!

Mức độ: Senior.

Bám chính sách sản phẩm và yêu cầu áp dụng đã được đội phụ trách xác nhận; test opt-in/out, đổi lựa chọn, retention và xóa dữ liệu theo phạm vi.

18. Senior/Lead và vòng Head of Tech#

189. Bạn xây kế hoạch 30–60–90 ngày cho vị trí này thế nào?#!

Mức độ: Lead.

30 ngày hiểu sản phẩm/rủi ro và baseline; 60 ngày cải thiện một luồng automation/security quan trọng; 90 ngày mở rộng coverage và quy trình dựa trên kết quả.

190. Bạn xử lý bất đồng go/no-go với Product hoặc Head of Tech thế nào?#!

Mức độ: Lead.

Trình bày impact, likelihood, evidence, phạm vi ảnh hưởng và lựa chọn giảm thiểu; nêu khuyến nghị rõ cùng người chấp nhận rủi ro.

191. Bạn mentor một QC viết test yếu thế nào?#!

Mức độ: Lead.

Xem một tác vụ thật, xác định thiếu nghiệp vụ, oracle hay kỹ thuật; pair thiết kế case, review có lý do và giao bài nâng dần.

192. Quality metrics nào hữu ích và dễ bị lạm dụng?#!

Mức độ: Lead.

Theo dõi escaped defects theo impact, thời gian phát hiện/khắc phục, flaky rate, risk coverage và feedback time. Dùng bối cảnh, không xếp hạng cá nhân bằng số bug.

193. Nếu bỏ sót lỗi production, bạn trả lời Head of Tech thế nào?#!

Mức độ: Senior.

Nhận phần trách nhiệm có thật, hỗ trợ containment, đối chiếu evidence và tìm khoảng trống trong requirement, test hoặc monitoring; bổ sung biện pháp phòng ngừa cụ thể.

194. Bạn nên hỏi gì ngược lại nhà tuyển dụng?#!

Mức độ: Senior.

Hỏi kỳ vọng Member/Lead, ownership, kiến trúc E2EE/recovery, IdP/IAM, baseline automation, release process và tiêu chí thành công. Làm rõ điều kiện onsite/Dubai theo JD.

19. Bài tập thực hành và khung đáp án#

195. Bài tập: thiết kế negative API test chống đọc file chéo tenant.#!

Mức độ: Senior.

Chuẩn bị hai tenant độc lập, owner đọc được file và outsider bị từ chối đúng contract. Xác minh response không chứa nội dung/metadata nhạy cảm và không có side effect.

196. Bài tập: viết SQL tìm tổng refund vượt số đã thu.#!

Mức độ: Senior.

Tổng hợp captured payments và successful refunds riêng theo tenant/order rồi mới JOIN. Dùng đơn vị tiền nhất quán, tránh nhân số dòng do join hai quan hệ một-nhiều.

197. Bài tập: viết hàm Python tính số tiền còn có thể refund.#!

Mức độ: Middle.

Validate amount là số nguyên không âm theo minor units, trừ các refund thành công và từ chối dữ liệu tổng hoàn vượt tiền thu.

198. Bài tập: viết Java API test kiểm tra viewer không xóa được file.#!

Mức độ: Senior.

Dùng Rest Assured với token viewer và file owner đã tạo; assert deny đúng contract, rồi owner đọc lại xác nhận file vẫn tồn tại.

199. Bài tập: thiết kế test tamper cho file E2EE chia chunk.#!

Mức độ: Senior.

Tạo file nhiều chunk, kiểm tra round-trip rồi lần lượt sửa byte, tag, index, manifest và tráo chunk giữa hai file. Mọi vi phạm xác thực phải bị phát hiện.

200. Bài tập: lập test plan trong 45 phút cho sản phẩm của JD.#!

Mức độ: Lead.

Làm rõ threat model/kiến trúc, chọn risk, xác định coverage theo lớp, dữ liệu/môi trường, automation, performance, release gate và phần chưa biết.