QA / Test Engineer

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Cơ bảnMột pure function tính VAT và làm tròn cho tổng đơn hàng. Phần lớn các edge case về làm tròn nên được kiểm ở đâu?

   Trong load test gửi nhiều tổng đơn hàng khác nhau vào APITrong unit test gọi trực tiếp function với nhiều inputTrong E2E test đi qua toàn bộ UI checkout cho từng caseTrong đợt regression thủ công QA chạy trước mỗi release
2. Câu 2/4·Cơ bảnMột manager hỏi vì sao 2.000 test pass vẫn không chứng minh được release không có bug. Nguyên tắc kiểm thử nào trả lời câu này?

   Kiểm thử sớm trong vòng đời giúp tiết kiệm thời gian và chi phíKiểm thử cho thấy có defect, không chứng minh được là không có defectDefect thường tập trung ở một số ít moduleLặp lại cùng bộ test thì dần dần không tìm thêm bug mới
3. Câu 3/4·Cơ bảnBạn có hai ngày để test một release chạm vào luồng thanh toán, trang giới thiệu và upload avatar. Risk-based testing chia công sức thế nào?

   Chia đều thời gian cho mỗi khu vực để báo cáo coverage trông cân đốiBắt đầu với khu vực đã có nhiều test case viết sẵn nhấtĐánh giá khả năng xảy ra nhân mức ảnh hưởng, nên thanh toán được kiểm sâu nhấtTập trung vào thay đổi được merge sau cùng vì nó mới nhất
4. Câu 4/4·Cơ bảnTrong buổi refinement, một story ghi 'Người dùng có thể áp mã giảm giá'. Hành động shift-left có giá trị nhất của QA là gì?

   Đợi bản build đầu tiên rồi viết test case dựa trên những gì UI hiển thịHỏi về mã hết hạn, mã dùng lại, mã cộng dồn và ghi thành tiêu chí Given/When/ThenƯớc lượng story cần bao nhiêu test case và thêm vào kế hoạch sprintYêu cầu developer viết E2E test cho story trước khi được merge

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Cơ bảnTrường tuổi chấp nhận từ 18 đến 65, tính cả hai đầu. Bộ giá trị nào áp dụng boundary value analysis đúng?

   0, 18, 65 và 10017, 18, 65 và 6618, 40 và 6519, 30, 50 và 64
2. Câu 2/4·Cơ bảnVì sao pairwise testing giảm mạnh số case mà vẫn bắt được phần lớn bug cấu hình?

   Phần lớn bug tương tác chỉ xuất hiện khi hai giá trị tham số kết hợp với nhauNó vẫn chạy mọi tổ hợp, chỉ là chia ra nhiều worker song songNó chỉ test giá trị mặc định của mỗi tham số, là giá trị người dùng chọn nhiều nhấtNó bỏ các tham số ít thay đổi nên còn lại ít cột hơn
3. Câu 3/4·Cơ bảnMột đơn hàng đi qua draft, paid, shipped, delivered và chỉ được hủy trước khi giao. Test nào dễ lộ bug ẩn nhất?

   Thử hủy một đơn đã delivered và kỳ vọng hệ thống từ chốiKiểm tra đơn shipped có hiển thị mã vận đơnTạo liên tiếp nhiều đơn draft cho cùng một người dùngChuyển một đơn draft sang paid bằng thẻ test hợp lệ
4. Câu 4/4·Cơ bảnTiêu đề bug report nào hữu ích nhất cho developer nhận xử lý?

   Một số lỗi tìm thấy khi test trang checkout và profileCheckout không hoạt động, nhờ kiểm tra gấp trong hôm nayGẤP: thanh toán bị hỏng với người dùng, chặn releaseCheckout: nút Pay vẫn disabled sau khi nhập thẻ hợp lệ trên Safari 18

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Cơ bảnMột người dùng đã đăng nhập mở trang admin và API trả về 403. Điều đó cho bạn biết gì?

   Token bị thiếu hoặc hết hạn nên người dùng phải đăng nhập lạiRequest body không qua được validation ở một hoặc nhiều trườngResource đã bị xóa và không còn tồn tại trên serverServer biết người dùng là ai nhưng họ không có quyền với resource này
2. Câu 2/4·Cơ bảnMột API call chạy được trong Postman nhưng lỗi CORS trên trình duyệt. Vì sao?

   API từ chối mọi request không có header User-AgentPostman gửi HTTP method khác với trình duyệtTrình duyệt mới là nơi áp CORS, và server chưa cho phép origin của trang nàyCache của trình duyệt vẫn đang trả response cũ
3. Câu 3/4·Cơ bảnTrang danh sách hiển thị 'Chưa có mục nào' với người dùng đã có dữ liệu. Tab Network cho thấy request danh sách trả 500. Bạn nên báo bug thế nào?

   Là bug UI về thông báo empty state sai, không cần chi tiết APILà test flaky, vì refresh trang đôi khi làm lỗi biến mấtLà bug API kèm status, request ID và body, ghi chú thêm UI che lỗi thành empty stateLà vấn đề test data, nhờ người khác seed lại database staging
4. Câu 4/4·Cơ bảnVì sao tự động retry một PUT thường an toàn hơn retry một POST?

   Trình duyệt cache response của PUT nên retry không bao giờ tới serverPUT có idempotency nên gửi lại vẫn ra cùng trạng thái, còn POST có thể tạo bản ghi trùngPUT luôn được mã hóa, còn POST mặc định thì khôngPUT không thể mang request body nên retry không có gì để trùng

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpTrong một test Playwright, page.click('#save'); expect(page.getByText('Saved')).toBeVisible(); không có await. Vấn đề là gì?

   Chỉ click cần await; web-first assertion chạy đồng bộTest cần waitForTimeout trước assertion mới chạy đúngKhông sao, vì Playwright tự await mọi actionTest có thể kết thúc trước khi các action chạy, nên dễ pass giả hoặc ném lỗi lạc chỗ
2. Câu 2/4·Trung cấpPhần setup tạo ba test user độc lập bằng await Promise.all([...]). Cách này mang lại gì?

   Các user được tạo đúng theo thứ tự mảng, lần lượt từng cáiMỗi request được tự động retry cho đến khi thành côngPromise bị reject sẽ bị bỏ qua nên setup không bao giờ hỏng giữa chừngCác request chạy đồng thời, và setup thất bại nếu bất kỳ request nào reject
3. Câu 3/4·Trung cấpTest B chỉ pass khi test A chạy trước, vì A tạo user mà B dùng để đăng nhập. Hệ quả là gì?

   Runner phát hiện phụ thuộc và tự chạy A trướcB chạy nhanh hơn vì dùng lại được dữ liệu A đã tạoB sẽ fail khi chạy riêng, xáo thứ tự hoặc song song, vì lý do không liên quan tới tính năngKhông sao, vì thứ tự test luôn ổn định ở mọi runner
4. Câu 4/4·Trung cấpMột pull request sửa helper định dạng ngày dùng chung cho hóa đơn và báo cáo. Bạn nên tập trung test ở đâu?

   Luồng đăng nhập, vì đó là phần được dùng nhiều nhấtKhông cần thêm gì, vì helper đã có unit test riêngMọi màn hình và file export dùng helper này, nhất là hóa đơn và báo cáo ở nhiều múi giờChỉ các file có trong diff, vì những chỗ khác không bị đụng tới

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpBạn test lỗ hổng broken object level authorization (BOLA) trên GET /orders/{id} thế nào?

   Gửi request không kèm token và kỳ vọng response 401Gửi 1.000 request mỗi giây và kỳ vọng API trả 429Gửi id sai định dạng và kỳ vọng lỗi validation 400Dùng token của user A để lấy đơn hàng thuộc user B và kỳ vọng 403 hoặc 404
2. Câu 2/4·Trung cấpVì sao nên validate mỗi response theo OpenAPI schema trước khi assert các giá trị cụ thể?

   Nó bắt rẻ các lỗi đổi tên field, đổi kiểu và null bất ngờ trên mọi responseNó chứng minh các quy tắc nghiệp vụ đằng sau từng giá trị là đúngNó thay thế việc phải test authorization và phân quyềnNó làm request nhanh hơn vì server trả body nhỏ hơn
3. Câu 3/4·Trung cấpMột contract test Pact giữa web app và orders API nên kiểm điều gì?

   Web app hiển thị đúng danh sách đơn hàng trên màn hìnhHình dạng request và response mà consumer dựa vào vẫn được giữ đúngProvider đạt mục tiêu latency p95 khi chịu tảiProvider tính đúng mọi quy tắc giảm giá
4. Câu 4/4·Trung cấpTrước khi release phiên bản consumer mới, team chạy can-i-deploy với Pact Broker. Lệnh này trả lời câu hỏi gì?

   Môi trường đích có đủ tài nguyên cho bản release khôngRelease notes và changelog của phiên bản đã đầy đủ chưaPhiên bản provider trong môi trường đó đã verify pact của consumer này chưaPhiên bản consumer mới đã pass bộ unit test của chính nó chưa

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpawait page.getByRole('button', { name: 'Delete' }).click() chạy trên trang có hai nút Delete khớp. Điều gì xảy ra?

   Playwright ném lỗi strict mode violation thay vì đoánPlaywright lần lượt click cả hai nútPlaywright click nút khớp đầu tiên theo thứ tự DOMPlaywright đợi một nút biến mất rồi mới click
2. Câu 2/4·Trung cấpMột test bị flaky vì toast 'Saved' đôi khi xuất hiện sau 2 giây. Cách sửa nào đúng?

   Tăng retries lên 3 trong config để lần chạy chậm có thêm cơ hộiKiểm await page.getByText('Saved').isVisible() một lần trong ifThêm await page.waitForTimeout(3000) ngay trước khi kiểm toastDùng await expect(page.getByText('Saved')).toBeVisible(), assertion tự retry tới timeout
3. Câu 3/4·Trung cấpMỗi test trong bộ 300 test đều đăng nhập qua UI trước. Cải tiến được khuyến nghị là gì?

   Dùng chung một browser context cho mọi test để giữ sessionTắt hẳn authentication trên môi trường testĐăng nhập một lần trong setup project, lưu storageState và dùng lại trong các testChạy tuần tự cả bộ để mỗi lúc chỉ có một lần đăng nhập
4. Câu 4/4·Trung cấpVì sao tăng retries để giữ pipeline xanh là thói quen rủi ro?

   Retry làm mọi test pass chạy chậm đi rõ rệtRetry có thể che giấu bug race condition thật mà người dùng cũng sẽ gặpRetry tắt việc ghi trace ở các lần chạy failRetry buộc mọi test chạy tuần tự theo thứ tự cố định

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpBạn chia bộ test Playwright ra 4 máy CI bằng --shard. Làm sao có một HTML report duy nhất?

   Dùng reporter blob ở mỗi shard rồi chạy npx playwright merge-reportsDùng reporter list, reporter này tự gộp output các shardTải HTML report của từng shard về và giữ bản mới nhấtĐặt workers: 4 trên một máy thay vì shard, vì shard không gộp được
2. Câu 2/4·Trung cấpScreenshot test pass ở máy local nhưng fail trên CI vì khác biệt nhỏ về font và khử răng cưa. Nguyên nhân khả dĩ nhất là gì?

   CI chạy nhanh hơn nên chụp màn hình trước khi animation kết thúcBaseline được chụp trên laptop có font và cách render khác container CISo sánh hình ảnh không được hỗ trợ khi trình duyệt chạy headlessNgưỡng diff phải đặt bằng 0 cho các lần so sánh trên CI
3. Câu 3/4·Trung cấpTest fail trên staging vì có người sửa tài khoản test dùng chung. Cách nào khắc phục tốt nhất?

   Khóa tài khoản dùng chung để không ai trong team sửa đượcKhôi phục snapshot toàn bộ database mỗi sáng trước khi chạyTạo dữ liệu mới cho từng test qua API hoặc factory, có namespace và dọn dẹpRetry các test fail cho tới khi dữ liệu dùng chung tình cờ đúng
4. Câu 4/4·Trung cấpVì sao chặn merge pull request bằng tầng test nhanh, còn bộ E2E đầy đủ chạy theo lịch hoặc trước release?

   Developer nhận phản hồi trong vài phút mà bộ đầy đủ vẫn chạy trước khi phát hànhTầng nhanh tìm được nhiều bug hơn bộ đầy đủ nên bộ đầy đủ là tùy chọnBộ E2E đầy đủ hoàn toàn không chạy được trong container CIChạy theo lịch là miễn phí vì phút CI ban đêm không tính tiền

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpBạn nên chọn thiết bị cho ma trận test mobile thế nào?

   Mẫu flagship mới nhất của mỗi hãng lớn trên thị trườngCác emulator image có sẵn mặc định trong IDEChỉ những thiết bị thật mà team đang có trong tayDựa trên analytics người dùng thật về thiết bị và phiên bản OS, xem lại mỗi quý
2. Câu 2/4·Trung cấpNgười dùng điền một form dài, chuyển sang app camera rồi quay lại thì form trống trơn. Test nào sẽ bắt được lỗi này?

   Đưa app xuống background giữa chừng, để OS kill rồi khôi phục lạiSubmit form với một trường bắt buộc để trốngMở cùng form đó trên emulator cỡ tabletXoay thiết bị giữa dọc và ngang khi đang ở form
3. Câu 3/4·Trung cấpVì sao Maestro hợp với smoke test nhanh trên app React Native, Flutter và native?

   Nó biên dịch test vào binary của app nên chạy nhanh hơn công cụ khácNó chỉ chạy trên thiết bị thật nên kết quả luôn sát thực tếNó chạy flow YAML trên bản release không cần instrumentation và có sẵn cơ chế chờNó thay thế unit test mà developer mobile lẽ ra phải viết
4. Câu 4/4·Trung cấpTest Appium của bạn vỡ mỗi khi designer chỉnh câu chữ hoặc layout. Cách khắc phục hiệu quả nhất là gì?

   Chỉ chạy bộ test trên emulator mới nhất để giảm biến độngThêm sleep cố định năm giây trước mỗi thao tácĐổi mọi locator sang XPath tuyệt đối copy từ inspectorThêm accessibility identifier hoặc testID ổn định và tìm element theo chúng

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Nâng caoMột load test báo thời gian phản hồi trung bình 180 ms và p99 là 4 s. Bạn nên kết luận gì?

   Chỉ vài request đầu chậm, nên warm-up giải thích toàn bộ chênh lệchHệ thống ổn, vì trung bình thấp hơn nhiều so với mục tiêuKhoảng 1 trên 100 request mất từ 4 s trở lên, phần đuôi mà người dùng thật cảm nhận đượcCông cụ đo sai, vì p99 không thể cách trung bình xa như vậy
2. Câu 2/4·Nâng caoTùy chọn k6 nào làm lần chạy tự fail khi latency bị thoái lui?

   console.log(res.timings.duration) trong mỗi iterationsleep(1) giữa các request trong default functionvus: 1000 kèm duration dài trong optionsthresholds: { http_req_duration: ['p(95)<500'] }
3. Câu 3/4·Nâng caoaxe báo không có vi phạm nào ở trang đăng ký. Vì sao bạn chưa thể nói trang đã accessible?

   Công cụ tự động chỉ bắt được một phần; kiểm bàn phím, focus và screen reader cần con ngườiaxe chỉ kiểm độ tương phản màu, bỏ qua label và ARIAWCAG 2.2 không bao gồm form nên trang đăng ký cần tiêu chuẩn khácKết quả axe thay đổi ngẫu nhiên giữa các lần chạy nên một lần không chứng minh gì
4. Câu 4/4·Nâng caoKhi đăng nhập bằng tài khoản của bạn, test nào kiểm lỗ hổng IDOR?

   Đổi ID trong GET /invoices/1042 sang ID hóa đơn của khách hàng khácKiểm tra request HTTP thường có được chuyển hướng sang HTTPSNhập <script>alert(1)</script> vào trường tên trong profileSubmit form đăng nhập 50 lần với mật khẩu sai

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Nâng caoVì sao code coverage là KPI yếu để đo chất lượng test?

   Nó đếm số lượng test thay vì số dòng được chạyNó cho biết dòng nào chưa từng chạy, không cho biết assertion có bắt được hành vi sai khôngNó chỉ áp dụng cho backend, không đo được frontendNó quá tốn kém để thu thập ở mỗi lần chạy CI
2. Câu 2/4·Nâng caoMột trang checkout mới được phát hành sau feature flag, rollout cho 10% người dùng. QA phải test gì trước khi rollout?

   Chỉ trạng thái tắt, vì 90% người dùng vẫn thấy nóChỉ trạng thái bật, vì code mới nằm ở đóChưa cần test gì, đợi flag lên 100% rồi tínhCả trạng thái bật và tắt, cùng các tổ hợp quan trọng với những flag đang bật khác
3. Câu 3/4·Nâng caoMột công cụ self-healing tự cập nhật locator sau khi nhãn nút đổi từ 'Pay' thành 'Pya'. Vì sao các bản sửa như vậy phải qua review?

   Healing có thể chấp nhận một thay đổi UI sai, biến bug thật thành test xanhLocator đã heal chỉ chạy được ở local, không chạy được trên CIMọi thay đổi file trong repo đều cần hai approval bất kể nội dungHealer chậm hơn sửa locator bằng tay nên review giúp tiết kiệm thời gian
4. Câu 4/4·Nâng caoBạn nên test tính năng trả lời hỗ trợ dùng LLM thế nào trước mỗi release?

   Chỉ kiểm endpoint trả 200 trong ngân sách latencyChạy eval set từ case thật, chấm bằng rule hoặc LLM-as-judge đã hiệu chỉnh, trong CIThử tay mười prompt trước mỗi release và thấy ổn là đượcAssert khớp chính xác chuỗi câu trả lời mong đợi cho từng prompt