QA Automation Engineer

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

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.

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.

N+1 xảy ra khi bạn lấy N bản ghi bằng 1 query, rồi mỗi lần truy cập quan hệ lazy lại phát sinh thêm 1 query. Ví dụ lấy 100 đơn hàng, rồi gọi order.getCustomer() trong vòng lặp là thành 101 query.

Cách xử lý:

• JOIN FETCH trong JPQL: select o from Order o join fetch o.customer.
• @EntityGraph(attributePaths = "customer") trên method của repository.
• @BatchSize hoặc hibernate.default_batch_fetch_size để gom lazy load thành câu IN (...).
• Với màn hình chỉ đọc, trả thẳng DTO projection thay vì entity.

Phát hiện bằng cách bật log SQL (spring.jpa.show-sql hoặc log của Hibernate) khi dev, hoặc dùng thống kê của Hibernate.

Hay sai: đổi sang FetchType.EAGER cho xong. Cách này chỉ đổi chỗ lỗi và làm mọi truy vấn khác nặng hơn. Fetch join nhiều collection cùng lúc cũng dễ gây tích Descartes.

N+1 là khi lấy danh sách bằng 1 query, rồi mỗi phần tử truy cập quan hệ lại sinh thêm 1 query. Ví dụ duyệt 50 bài viết và in post.author.name sẽ thành 51 query.

• select_related: dùng SQL JOIN, cho quan hệ trỏ tới một object (ForeignKey, OneToOne).
• prefetch_related: chạy query riêng rồi ghép trong Python, cho quan hệ nhiều (ManyToMany, reverse ForeignKey).

posts = (Post.objects
         .select_related("author")
         .prefetch_related("tags"))

Phát hiện bằng Django Debug Toolbar, hoặc assertNumQueries trong test.

Hay sai: gọi .filter() trên quan hệ đã prefetch bên trong vòng lặp. Lệnh đó tạo query mới và bỏ qua dữ liệu prefetch; dùng Prefetch(..., queryset=...) để lọc ngay từ đầu.

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.

"Yes, for the last two years I've worked with a client in Europe, so we only had about three overlapping hours a day. To make the most of that time, we kept a short daily call and I prepared questions in advance. For everything else, I wrote clear updates in Jira and Slack so they could reply when they started their day. This helped us avoid waiting a whole day for answers."

Mẹo: nhấn vào cách bạn giao tiếp chủ động và viết rõ ràng. Dùng "overlapping hours", "asynchronous communication", "I kept them updated". Tránh nói "I have worked with them since 2 years", đúng là "for two years".

Chọn sai lầm thật, có hậu quả vừa phải, nhận trách nhiệm rõ ràng, và nhấn mạnh việc bạn đã thay đổi sau đó.

Cấu trúc: chuyện gì xảy ra, phần lỗi của bạn, bạn khắc phục ngay thế nào, bài học và thay đổi lâu dài.

Câu mẫu: "Có lần em deploy một thay đổi cấu hình lên production vào chiều thứ Sáu mà không kiểm tra kỹ trên staging, làm một tính năng lỗi khoảng một giờ. Em báo ngay cho lead, rollback và viết báo cáo sự cố. Sau đó em đề xuất checklist trước deploy và quy ước hạn chế deploy cuối tuần; team áp dụng tới giờ."

Hay sai: kể một "thất bại" thực ra là khoe, đổ lỗi cho người khác, hoặc nói mình chưa từng thất bại.