Junior/ Senior Full-stack Tester (Auto & Manual)

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.

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.

Hallucination là khi mô hình sinh ra nội dung nghe hợp lý nhưng sai hoặc không có căn cứ. Không loại bỏ hoàn toàn được, chỉ giảm và kiểm soát.

• Cung cấp ngữ cảnh đúng qua RAG, yêu cầu chỉ trả lời dựa trên nguồn và trích dẫn.
• Cho phép và khuyến khích trả lời "không đủ thông tin".
• Dùng đầu ra có cấu trúc (JSON schema) và kiểm tra hợp lệ bằng code.
• Với số liệu, tra cứu hoặc tính toán qua tool/API thay vì để mô hình tự nhớ.
• Kiểm tra sau sinh: đối chiếu câu trả lời với nguồn.
• Thiết kế UX hiển thị nguồn; tác vụ rủi ro cao có người duyệt.

Người phỏng vấn muốn nghe: đo tỷ lệ hallucination bằng bộ đánh giá, không chỉ dựa vào cảm giác.

Mô hình lên production là một phần mềm cần đóng gói, phiên bản hoá, giám sát và cập nhật như mọi dịch vụ khác.

• Đóng gói: lưu mô hình kèm phiên bản dữ liệu, code, siêu tham số (model registry).
• Phục vụ: API online hoặc chạy batch tuỳ yêu cầu độ trễ; dùng chung code tính đặc trưng giữa train và serve để tránh lệch.
• Triển khai an toàn: shadow hoặc canary, so sánh với mô hình cũ.
• Giám sát: độ trễ, lỗi; data drift (phân phối đầu vào thay đổi); chất lượng dự đoán khi có nhãn thật.
• Cập nhật: train lại định kỳ hoặc khi drift vượt ngưỡng, có rollback.

Hay sai: training-serving skew, xử lý đặc trưng ở hai nơi bằng hai đoạn code khác nhau.

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".

Chia theo nhóm để không sót, rồi áp dụng kỹ thuật thiết kế test.

• Chức năng: đúng email/mật khẩu; sai mật khẩu; email chưa đăng ký; để trống từng trường.
• Phân vùng tương đương & giá trị biên: độ dài mật khẩu ở min-1, min, max, max+1; email sai định dạng.
• Bảo mật: khoá tài khoản sau N lần sai, mật khẩu bị che, thông báo lỗi không tiết lộ email có tồn tại hay không, thử ký tự đặc biệt/SQL injection cơ bản.
• UI/UX: nhấn Enter để submit, tab order, hiện/ẩn mật khẩu, thông báo lỗi rõ ràng.
• Khác: "Ghi nhớ đăng nhập", session hết hạn, nhiều trình duyệt/thiết bị.

Hay sai: chỉ liệt kê case happy path, hoặc liệt kê lan man không có nhóm. Nên nói thêm mỗi test case gồm: tiền điều kiện, các bước, dữ liệu, kết quả mong đợi.

Bug report tốt giúp dev tái hiện được ngay mà không cần hỏi lại.

• Tiêu đề ngắn, nói rõ chỗ lỗi và hiện tượng.
• Môi trường: build/version, trình duyệt hoặc thiết bị, tài khoản test.
• Các bước tái hiện, kết quả thực tế, kết quả mong đợi.
• Bằng chứng: ảnh, video, log, request/response.
• Severity, Priority, tần suất (luôn xảy ra hay thỉnh thoảng).

Severity là mức ảnh hưởng kỹ thuật (crash, mất dữ liệu là Critical). Priority là mức gấp cần sửa theo góc nhìn business. Ví dụ: logo sai màu ở trang chủ có severity thấp nhưng priority cao trước buổi demo khách hàng; app crash ở một màn hình gần như không ai dùng có severity cao nhưng priority có thể thấp hơn.

Hay sai: tự đặt Priority thay cho PO/PM mà không trao đổi.

"I'm working on an e-commerce platform that handles orders for several retail brands. The system is built with microservices on Node.js, using PostgreSQL and Redis, deployed on AWS. My team has six people and we work in two-week sprints. I'm mainly in charge of the order and payment services. Recently, I led the integration with a new payment gateway, from reading the API docs to handling edge cases like timeouts and duplicate callbacks."

Mẹo: đi từ tổng quan (sản phẩm làm gì, cho ai) tới vai trò của riêng bạn. Nói "my team" và "I" rõ ràng để người nghe biết phần nào bạn làm. Không cần kể tên khách hàng nếu bị ràng buộc bảo mật.

Trả lời thật nhưng hướng về phía trước: nói điều bạn đang tìm kiếm, không kể xấu nơi cũ.

Lý do chấp nhận được: muốn thử thách mới, muốn làm sản phẩm, dự án kết thúc, công ty tái cấu trúc, thu nhập chưa tương xứng (nói khéo).

Câu mẫu: "Em đã làm 2 năm ở dự án outsourcing, học được nhiều về quy trình và làm việc với khách nước ngoài. Giờ em muốn gắn bó lâu dài với một sản phẩm để thấy được tác động của những gì mình làm, và vị trí bên mình đúng hướng đó."

Hay sai: chê sếp, chê đồng nghiệp, kể chuyện drama. Người phỏng vấn sẽ nghĩ bạn cũng sẽ nói về công ty họ như vậy. Nếu nhảy việc nhiều, chuẩn bị lời giải thích cho từng lần.