Ở Waterfall, QA thường chỉ tham gia ở cuối (sau khi dev hoàn thành) — trong Agile, QA tham gia xuyên suốt sprint, từ lúc refine requirement tới khi tính năng release, và thường làm việc song song với dev thay vì tuần tự sau đó.
"QA nên tham gia vào giai đoạn nào của sprint?" — Câu trả lời tốt nhấn mạnh QA nên tham gia ngay từ sprint planning/refinement — đặt câu hỏi làm rõ acceptance criteria, xác định testable requirement trước khi dev bắt đầu code, không đợi tới khi code xong mới bắt đầu nghĩ về test case.
"Sprint sắp kết thúc nhưng vẫn còn nhiều bug chưa test hết, bạn xử lý thế nào?" — Không nên âm thầm bỏ qua test để kịp deadline — cần giao tiếp rõ ràng với team về rủi ro (tính năng nào đã test kỹ, tính năng nào còn rủi ro), để Product Owner quyết định có defer sang sprint sau hay chấp nhận rủi ro đã biết để release đúng hạn — quyết định là của team, không phải QA tự ý bỏ qua.
"Definition of Done nên bao gồm những gì liên quan tới QA?" — Không chỉ "code đã viết xong" mà cần: test case đã viết và pass, không có bug nghiêm trọng mở, code đã qua review, và (nếu áp dụng) test automation đã cập nhật cho tính năng mới — Definition of Done rõ ràng giúp cả team thống nhất "xong" nghĩa là gì, tránh tranh cãi cuối sprint.
"Dev và QA bất đồng về việc 1 hành vi là bug hay tính năng đúng thiết kế, bạn xử lý thế nào?" — Không nên tranh cãi dựa trên ý kiến cá nhân — cần quay lại requirement/acceptance criteria gốc làm căn cứ, nếu vẫn mơ hồ thì hỏi lại Product Owner để có quyết định rõ ràng, tránh để bất đồng kéo dài ảnh hưởng tiến độ.
"Bạn nghĩ QA nên viết unit test hay chỉ dev viết?" — Quan điểm phổ biến hiện nay: dev chịu trách nhiệm chính cho unit test (vì hiểu code implementation nhất), QA tập trung vào integration/E2E test và tư duy kiểm thử ở góc nhìn người dùng — nhưng ranh giới này linh hoạt tuỳ văn hoá từng team, câu trả lời tốt thể hiện hiểu rõ đây không phải ranh giới cứng nhắc.
Đưa hoạt động test càng sớm càng tốt trong vòng đời phát triển (review requirement, viết test case song song lúc dev code, thậm chí TDD) thay vì chỉ test sau khi code hoàn thành — giảm chi phí sửa bug đáng kể vì phát hiện vấn đề càng sớm càng rẻ để fix.
Kể 1 tình huống thực tế về hợp tác/xung đột trong Agile team và cách bạn giải quyết dựa trên dữ liệu/quy trình rõ ràng thay vì cảm tính — thể hiện tư duy làm việc nhóm chuyên nghiệp, không chỉ kỹ năng test thuần tuý.