Senior QC Engineer (Manual/Automation)

Bắt đầu từ hiểu hiện trạng và rủi ro, rồi cải thiện từng bước thay vì áp nguyên một quy trình nặng.

• Tuần đầu: tìm hiểu sản phẩm, luồng nghiệp vụ chính, lịch sử bug sau release, cách team đang làm việc.
• Nền tảng: thống nhất quy trình bug (template, severity, vòng đời ticket), Definition of Done có bước test, môi trường test tách khỏi production.
• Shift-left: tham gia refinement để làm rõ acceptance criteria trước khi code.
• Phủ test: bộ smoke cho luồng quan trọng, sau đó automation dần (ưu tiên API), đưa vào CI.
• Đo lường: số bug lọt ra production, thời gian xử lý bug, độ phủ regression, để chứng minh hiệu quả.

Người phỏng vấn muốn nghe: bạn biết ưu tiên, làm việc với dev chứ không đứng ngoài "bắt lỗi", và đo được kết quả.

Đừ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.

IoC container của Spring tạo và quản lý các bean, rồi "tiêm" phụ thuộc vào class cần dùng, thay vì class tự new. Nhờ vậy code ít phụ thuộc cứng, dễ thay implementation và dễ test.

Constructor injection được khuyên dùng vì:

• Field có thể là final, object luôn ở trạng thái đầy đủ sau khi tạo.
• Test unit không cần Spring: chỉ cần new OrderService(mockRepo).
• Constructor quá nhiều tham số là dấu hiệu class đang ôm nhiều việc.
• Class chỉ có một constructor thì không cần ghi @Autowired.

Nên nói thêm về scope: mặc định bean là singleton (một instance cho cả context), ngoài ra có prototype, request, session.

Hay sai: để state thay đổi được (ví dụ biến đếm, list) trong bean singleton. Nhiều request chạy song song sẽ dùng chung và gây race condition.

Spring tạo proxy bao quanh bean. Khi gọi method có @Transactional qua proxy, proxy mở transaction, gọi method thật, rồi commit hoặc rollback.

Những lý do hay gặp khiến nó "không ăn":

• Self-invocation: method A trong cùng class gọi this.b() có @Transactional, lời gọi không đi qua proxy.
• Method là private hoặc final: proxy không chặn được lời gọi.
• Mặc định chỉ rollback với unchecked exception và Error. Checked exception vẫn commit, trừ khi khai báo rollbackFor = Exception.class.
• Exception bị catch và nuốt bên trong method.

Nên biết thêm propagation (REQUIRED, REQUIRES_NEW) và readOnly = true cho các truy vấn chỉ đọc.

Người phỏng vấn muốn nghe: bạn giải thích được bằng cơ chế proxy, không chỉ liệt kê lỗi.

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.

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.

Chuyển sang test theo rủi ro (risk-based testing) và minh bạch với team về phần chưa test.

• Xác định thay đổi trong bản release và vùng code bị ảnh hưởng (hỏi dev, xem danh sách commit/ticket).
• Ưu tiên: luồng tạo ra tiền hoặc dữ liệu quan trọng (thanh toán, đăng nhập, đặt hàng), chỗ hay có bug trong quá khứ, tính năng mới.
• Chạy bộ automation sẵn có, người tập trung vào phần automation chưa phủ.
• Báo cáo rõ: đã test gì, chưa test gì, rủi ro còn lại, đề xuất (release có điều kiện, feature flag, theo dõi sau release).
• Quyết định release là của PO/PM dựa trên thông tin bạn đưa.

Người phỏng vấn muốn nghe: bạn không âm thầm bỏ qua test, cũng không cố chặn release; bạn cung cấp thông tin để team quyết định. Về lâu dài, đề xuất tăng automation cho regression.

Dùng STAR: Situation (bối cảnh), Task (nhiệm vụ), Action (bạn làm gì), Result (kết quả). Phần Action nên chiếm nhiều nhất.

Câu mẫu:

• S: "Lead muốn dùng một thư viện mới cho module báo cáo, em thấy thư viện đó còn ít người dùng và lo về bảo trì."
• T: "Em cần nêu rủi ro mà không làm chậm tiến độ."
• A: "Em gặp riêng anh, đưa so sánh hai phương án và đề xuất làm thử một bản nhỏ trong hai ngày để đánh giá."
• R: "Kết quả thử cho thấy thư viện cũ đáp ứng đủ, anh đồng ý giữ lại. Từ đó team có thói quen làm bản thử trước khi đổi công nghệ."

Người phỏng vấn muốn nghe: bạn tranh luận bằng dữ liệu, tôn trọng người khác, và chấp nhận quyết định cuối cùng kể cả khi không theo ý mình.