Thực tập sinh Tester

Ba loại này khác nhau ở mục đích và phạm vi.

• Smoke test: chạy nhanh các luồng chính ngay khi có build mới để quyết định build có đủ ổn để test tiếp không. Rộng nhưng nông.
• Sanity test: sau khi sửa một bug hay thay đổi nhỏ, kiểm tra nhanh đúng chỗ đó và vùng liên quan. Hẹp nhưng sâu.
• Regression test: kiểm tra lại các chức năng đã chạy đúng để chắc thay đổi mới không làm hỏng chúng. Phạm vi lớn nhất, hợp để automation.

Ví dụ trả lời: "Ở dự án trước, mỗi build lên môi trường test em chạy bộ smoke khoảng 20 case trong 15 phút. Fix bug thì sanity phần liên quan. Trước release cả team chạy regression, phần lặp lại đã được automation."

Người phỏng vấn muốn nghe: ví dụ thực tế từ dự án của bạn, không chỉ định nghĩa.

Đừng đợi tài liệu hoàn hảo; chủ động làm rõ và ghi lại giả định.

• Đặt câu hỏi cụ thể cho BA/PO ngay từ lúc refinement, ưu tiên những chỗ ảnh hưởng tới acceptance criteria.
• Tham khảo nguồn khác: bản thiết kế UI, hệ thống cũ, sản phẩm tương tự, hỏi dev về logic đã code.
• Viết test scenario ở mức cao trước, ghi rõ giả định, gửi lại cho BA/PO xác nhận.
• Kết hợp exploratory testing theo session có mục tiêu và ghi chú.
• Chỗ chưa rõ thì log thành câu hỏi/ticket thay vì tự quyết là bug hay không.

Người phỏng vấn muốn nghe: bạn chủ động và minh bạch. Ví dụ: "Em gửi danh sách 8 câu hỏi kèm giả định, PO trả lời 6, 2 câu còn lại em đánh dấu là rủi ro trong test report."

Giữ bình tĩnh, dựa vào bằng chứng và requirement, không tranh cãi cảm tính.

• Kiểm tra lại: đúng build, đúng môi trường, đúng dữ liệu chưa? Có thể do cache hoặc tài khoản test khác nhau.
• Bổ sung video, log, request/response; nếu được thì ngồi tái hiện cùng dev.
• Nếu tranh luận là "đúng thiết kế hay không", dẫn chiếu acceptance criteria. Requirement không nói rõ thì kéo BA/PO vào quyết định.
• Bug thỉnh thoảng mới xảy ra: ghi tần suất, điều kiện nghi ngờ, giữ ticket mở để theo dõi.

Hay sai: đóng ticket cho xong chuyện, hoặc biến nó thành chuyện cá nhân. Câu trả lời tốt cho thấy bạn coi dev là đồng đội cùng bảo vệ chất lượng.

Có. Composite index sắp xếp theo cột đầu, rồi đến cột thứ hai trong cùng giá trị cột đầu, v.v. Vì vậy nó chỉ dùng hiệu quả khi query dùng các cột từ trái sang (leftmost prefix).

Với INDEX (status, created_at):

• WHERE status = 'paid' AND created_at > ...: dùng tốt.
• WHERE status = 'paid' ORDER BY created_at DESC: dùng cho cả lọc lẫn sắp xếp.
• WHERE created_at > ... (không có status): thường không dùng được.

Nguyên tắc chọn thứ tự: cột so sánh bằng (=) đặt trước, cột so sánh khoảng hoặc sắp xếp đặt sau. Nếu index chứa đủ mọi cột query cần (covering index) thì DB không phải đọc lại bảng.

Hay sai: tạo riêng index cho từng cột rồi nghĩ rằng chúng sẽ kết hợp hiệu quả như một composite index.

Isolation level quyết định một transaction thấy được bao nhiêu thay đổi của transaction khác; mức càng cao càng an toàn nhưng càng dễ tranh chấp.

• Dirty read: đọc dữ liệu transaction khác chưa commit.
• Non-repeatable read: đọc lại cùng một dòng thấy giá trị đã đổi.
• Phantom read: chạy lại cùng điều kiện thấy thêm hoặc mất dòng.

Bốn mức chuẩn: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Mặc định của PostgreSQL, SQL Server, Oracle là Read Committed; MySQL InnoDB là Repeatable Read.

Thực tế các DB dùng MVCC nên hành vi có khác lý thuyết: Repeatable Read của PostgreSQL dùng snapshot nên không gặp phantom, còn InnoDB dùng gap lock cho câu đọc có khoá.

Người phỏng vấn muốn nghe: bạn biết DB mình dùng mặc định ở mức nào và đã từng xử lý lost update, vd. bằng SELECT ... FOR UPDATE hoặc optimistic locking.

Mỗi yêu cầu "nhỏ" cộng lại thành trễ hạn. Cần quy trình tiếp nhận thay đổi rõ ràng từ đầu dự án.

• Chốt phạm vi bằng tài liệu hoặc backlog đã thống nhất, kèm định nghĩa hoàn thành.
• Mọi yêu cầu mới đi qua một kênh: ghi nhận, đánh giá effort và ảnh hưởng tới mốc bàn giao.
• Đưa lựa chọn cho khách: đổi lấy hạng mục khác, dời mốc, tính thêm chi phí, hoặc để giai đoạn sau.
• Dự án fixed-price: dùng change request có ký duyệt. Dự án time & material: minh bạch ảnh hưởng tới ngân sách.
• Dặn team không nhận yêu cầu trực tiếp từ khách mà không qua PM/PO.

Người phỏng vấn muốn nghe: bạn vẫn giữ được quan hệ tốt với khách. Nói "có, và đây là cái giá" thay vì chỉ nói "không".

Test API là kiểm tra hợp đồng giữa client và server, không cần UI.

• Status code đúng từng trường hợp: 200/201, 400 khi dữ liệu sai, 401/403 khi thiếu quyền, 404, 409, 500.
• Response body: đúng schema, kiểu dữ liệu, trường bắt buộc, giá trị khớp DB.
• Validation: thiếu trường, sai kiểu, giá trị biên, chuỗi rất dài, ký tự đặc biệt.
• Phân quyền: user A có đọc/sửa được dữ liệu của user B không.
• Idempotency & trạng thái: gọi lại POST/PUT nhiều lần, thứ tự gọi API sai.
• Hiệu năng cơ bản: thời gian phản hồi, phân trang.

Công cụ hay dùng: Postman (collection, environment, script kiểm tra), sau đó đưa vào CI bằng Newman hoặc framework code như REST Assured, Playwright API.

Người phỏng vấn muốn nghe: bạn có test case phân quyền và lỗi, không chỉ gọi thử thấy 200 là xong.

Automation đáng tiền khi chạy lặp lại nhiều và ổn định; manual hợp với thứ thay đổi liên tục hoặc cần cảm nhận người dùng.

Nên automation:

• Bộ regression và smoke chạy mỗi build/release.
• Test API, tính toán nghiệp vụ nhiều bộ dữ liệu (data-driven).
• Luồng chính ít thay đổi giao diện.

Nên giữ manual:

• Tính năng mới, UI còn thay đổi theo sprint.
• Exploratory, usability, kiểm tra trực quan.
• Case chỉ chạy một hai lần, hoặc chi phí dựng môi trường quá lớn.

Nên nhắc chi phí bảo trì: script hỏng vì locator thay đổi cũng tốn thời gian. Ưu tiên tầng API/unit trước UI theo mô hình test pyramid.

Hay sai: nói "automation hết cho nhanh". Người phỏng vấn muốn thấy bạn biết tính ROI.

QA (Quality Assurance) lo quy trình để lỗi ít xảy ra ngay từ đầu; QC (Quality Control) kiểm tra sản phẩm để tìm lỗi đã xảy ra. Testing là một hoạt động chính của QC.

• QA: review requirement, đặt chuẩn Definition of Done, checklist review code, quy trình release.
• QC: viết và chạy test case, log bug, verify fix, regression.
• Thực tế ở Việt Nam, chức danh "QA" thường làm cả hai, nhưng phần lớn thời gian là QC.

Người phỏng vấn muốn nghe: bạn hiểu khái niệm và kể được việc cụ thể mình làm, ví dụ "Em tham gia review user story từ sprint planning để hỏi rõ acceptance criteria, rồi mới viết test case".

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.