1. Hãy giới thiệu ngắn gọn về bản thân bạn

Nêu theo công thức: học vấn/nền tảng → kinh nghiệm hoặc dự án liên quan → kỹ năng & công cụ → định hướng gắn với vị trí ứng tuyển. Dài khoảng 45–60 giây.

Ví dụ: “Em tốt nghiệp ngành Công nghệ phần mềm, có kinh nghiệm Manual Testing cho website thương mại điện tử và app mobile. Em nắm vững quy trình SDLC/STLC, thành thạo Jira và Postman, đang học thêm kiểm thử tự động. Em mong được phát triển sự nghiệp QA trong môi trường chuyên nghiệp của công ty.”

2. Theo bạn, kỹ năng quan trọng nhất của một Tester là gì?

Ba nhóm kỹ năng cốt lõi: tư duy phản biện & logic, sự tỉ mỉ – kiên nhẫn, và kỹ năng giao tiếp để phối hợp với Dev/BA/PM.

Tư duy logic giúp phân tích luồng hoạt động và phát hiện lỗi tiềm ẩn; sự cẩn thận giúp không bỏ sót edge case; giao tiếp tốt giúp mô tả và theo dõi lỗi hiệu quả. Xem đầy đủ 9 kỹ năng một Tester giỏi cần có.

3. Vì sao bạn nghĩ mình phù hợp với vị trí Tester tại công ty?

Gắn điểm mạnh cá nhân (tỉ mỉ, trách nhiệm, ham học) với nhu cầu thực tế của vị trí và sản phẩm của công ty — thể hiện bạn đã tìm hiểu về họ.

Nhấn mạnh động lực “muốn mang lại trải nghiệm hoàn hảo cho người dùng” thay vì chỉ “thích bắt lỗi”, cùng khả năng làm việc nhóm và thái độ chủ động.

1. Kiểm thử phần mềm là gì? Quy trình kiểm thử gồm những bước nào?

Kiểm thử phần mềm (Software Testing) là hoạt động đánh giá phần mềm nhằm phát hiện lỗi và đảm bảo sản phẩm đáp ứng yêu cầu chức năng & phi chức năng trước khi đến tay người dùng.

Một quy trình kiểm thử chuyên nghiệp gồm 6 bước:

1. Phân tích yêu cầu — hiểu rõ đặc tả, xác định phạm vi kiểm thử.
2. Lập kế hoạch kiểm thử — chiến lược, nguồn lực, công cụ, lịch trình.
3. Thiết kế & phát triển test case — cả trường hợp bình thường và ngoại lệ.
4. Thiết lập môi trường — chuẩn bị hệ thống, dữ liệu, công cụ.
5. Thực thi kiểm thử — chạy test, ghi nhận kết quả, báo lỗi.
6. Kết thúc kiểm thử — tổng hợp báo cáo, rút kinh nghiệm.

2. Phân biệt kiểm thử thủ công (Manual) và kiểm thử tự động (Automation)

Manual Testing do con người trực tiếp thực hiện, hợp với kiểm thử thăm dò và dự án nhỏ; Automation Testing dùng script/công cụ, hợp với test lặp lại nhiều lần như hồi quy, hiệu năng, data-driven.

Mẹo trả lời: Đừng nói “automation luôn tốt hơn”. Tester giỏi biết khi nào KHÔNG nên tự động hóa — ví dụ test thăm dò (exploratory) hoặc tính năng thay đổi liên tục.

3. Phân biệt Test scenario, Test case và Test script

Ba khái niệm khác nhau ở mức độ chi tiết: Test scenario là tình huống tổng quan; Test case là các bước chi tiết kiểm tra một tính năng; Test script là tập lệnh tự động thực thi test case.

4. Phân biệt Verification và Validation

Verification kiểm tra “sản phẩm được xây đúng cách chưa?” (đúng đặc tả, qua review/inspection). Validation kiểm tra “sản phẩm có đúng thứ người dùng cần không?” (qua chạy thử phần mềm thật).

5. Phân biệt Severity và Priority của một lỗi

Severity (mức nghiêm trọng) phản ánh lỗi ảnh hưởng kỹ thuật lớn đến đâu; Priority (mức ưu tiên) phản ánh lỗi cần được sửa sớm đến mức nào về mặt nghiệp vụ. Hai giá trị này độc lập với nhau.

6. Vòng đời một lỗi (Defect/Bug Life Cycle) gồm những trạng thái nào?

Vòng đời lỗi là chuỗi trạng thái một bug đi qua từ khi được phát hiện đến khi đóng: New → Assigned → Open → Fixed → Retest → Verified → Closed. Nếu lỗi tái xuất, chuyển sang Reopened.

Ngoài ra có các trạng thái phụ: Rejected (dev cho rằng không phải lỗi), Duplicate (trùng lỗi đã có), Deferred (hoãn sửa sang bản sau).

7. Boundary Value Analysis và Equivalence Partitioning là gì?

Đây là 2 kỹ thuật thiết kế test case hộp đen giúp giảm số lượng test mà vẫn bao phủ tốt. Equivalence Partitioning chia dữ liệu thành các nhóm tương đương; Boundary Value Analysis kiểm thử tại các giá trị biên của mỗi nhóm.

Ví dụ trường nhập tuổi hợp lệ 18–60: chia nhóm (dưới 18 / 18–60 / trên 60) rồi test tại các biên 17, 18, 60, 61 — nơi lỗi hay xuất hiện nhất.

8. Mô hình chữ V (V-Model) khác mô hình thác nước (Waterfall) thế nào?

V-Model gắn mỗi giai đoạn phát triển với một hoạt động kiểm thử tương ứng ngay từ đầu; Waterfall chỉ kiểm thử sau khi phát triển xong toàn bộ, nên phát hiện lỗi muộn hơn.

Chốt ý: Cả hai gắn với nguyên lý kiểm thử sớm (early testing / shift-left) — theo nhiều nghiên cứu ngành phần mềm, chi phí sửa một lỗi tăng lên nhiều lần qua mỗi giai đoạn (phát hiện ở giai đoạn sản xuất có thể tốn kém gấp cả chục lần so với giai đoạn yêu cầu). Đây là lý do vì sao “bắt lỗi càng sớm càng rẻ”.

1. Vòng đời kiểm thử phần mềm (STLC) gồm những giai đoạn nào?

STLC gồm 6 giai đoạn: phân tích yêu cầu → lập kế hoạch kiểm thử → phát triển test case → thiết lập môi trường → thực hiện kiểm thử → kết thúc kiểm thử. Lưu ý phân biệt STLC (vòng đời kiểm thử) với SDLC (vòng đời phát triển phần mềm).

2. Kiểm thử hộp đen (Black-box) khác hộp trắng (White-box) ở đâu?

Black-box kiểm thử chức năng dựa trên đầu vào/đầu ra, không cần biết code bên trong (hợp với Tester mới); White-box kiểm thử logic bên trong, cần đọc code (thường do Dev/SDET đảm nhận).

3. Bạn hiểu Agile/Scrum trong kiểm thử như thế nào?

Trong Agile, Tester tham gia ngay từ sprint đầu, kiểm thử liên tục theo từng user story thay vì đợi cuối dự án; phối hợp chặt với Dev/BA/PO trong daily standup, sprint planning và review.

1. Nguyên tắc viết một test case tốt là gì?

Test case tốt cần: ngắn gọn – rõ ràng, bám sát yêu cầu, độc lập, đặt tên dễ hiểu, có thể tái sử dụng và dễ tự động hóa, ghi rõ kết quả mong đợi.

2. Bạn sắp xếp mức độ ưu tiên test case theo tiêu chí nào?

Ưu tiên theo: rủi ro (khu vực dễ lỗi/quan trọng), chức năng cốt lõi, tần suất người dùng, điểm tích hợp giữa module, hiệu năng, bảo mật, và yêu cầu của stakeholders. Nguyên tắc: “kiểm thử thông minh, không kiểm thử tất cả như nhau”.

3. Khi nào bạn quyết định dừng kiểm thử?

Dừng khi: đạt mức chất lượng mong muốn, hết thời gian/ngân sách theo kế hoạch, số bug mới giảm mạnh (chủ yếu lỗi nhỏ), phần lớn test case đã pass, và rủi ro còn lại ở mức chấp nhận được.

1. Một Tester giỏi cần những phẩm chất gì?

Tư duy chi tiết & quan sát tinh tế, hiểu domain sản phẩm, biết đặt mình vào vị trí người dùng, có tư duy kỹ thuật/đọc được code cơ bản, và giao tiếp – báo cáo lỗi rõ ràng.

2. Làm sao đo lường và đảm bảo độ bao phủ kiểm thử (test coverage)?

Dùng các chỉ số như requirement coverage (bao nhiêu yêu cầu có test case), test case coverage, và với automation là code coverage. Quan trọng hơn con số là bao phủ đúng vùng rủi ro cao — coverage 100% không đồng nghĩa hết lỗi.

3. Bạn xây dựng chiến lược kiểm thử (test strategy) cho một dự án mới ra sao?

Bắt đầu từ phân tích rủi ro và mục tiêu kinh doanh → xác định phạm vi, loại test (functional, performance, security), tỷ lệ manual/automation → chọn công cụ & môi trường → định nghĩa tiêu chí vào/ra (entry/exit criteria) và cách báo cáo.

1. Phát hiện lỗi nghiêm trọng ở giai đoạn cuối dự án, bạn xử lý thế nào?

Quy tắc: phản ứng nhanh – phối hợp – kiểm soát rủi ro. Đánh giá mức độ ảnh hưởng → báo cáo ngay qua kênh chính thức (Jira) → phối hợp Dev tìm nguyên nhân gốc & hướng khắc phục (hotfix/rollback) → retest và regression sau khi sửa.

2. Được giao kiểm thử tính năng mới mà không có tài liệu, bạn làm gì?

Chủ động trao đổi 10–15 phút với Dev/PO để nắm mục tiêu & luồng người dùng → chạy kiểm thử thăm dò theo charter → ưu tiên theo rủi ro (đăng nhập, thanh toán, dữ liệu biên) → ghi chép bằng mind map, đính kèm ảnh/quay màn hình khi báo lỗi.

3. Khách hàng vẫn phàn nàn dù bạn đã test đạt 100% yêu cầu?

Không phủ nhận vội — lắng nghe để hiểu trải nghiệm thực tế. Vấn đề có thể nằm ngoài phạm vi test (ví dụ cấu hình server, hiệu năng dưới tải thật). Phối hợp Dev điều tra nguyên nhân, đưa giải pháp và cập nhật lại bộ test cho lần sau.

1. AI đang thay đổi công việc của Tester như thế nào? AI có thay thế Tester không?

AI đang hỗ trợ chứ chưa thay thế Tester: nó giúp sinh test case, gợi ý locator, tóm tắt log lỗi và nhóm nguyên nhân — nhưng con người vẫn quyết định “đâu là rủi ro đáng test nhất” dựa trên hiểu biết nghiệp vụ & hành vi người dùng.

Theo World Quality Report 2025–26, khoảng 10% đội đã dùng GenAI sinh tới 75% script automation; vai trò Tester dịch chuyển sang review, tinh chỉnh và phán đoán rủi ro trên đầu ra của AI. (Nguồn: World Quality Report 2025–26.)

2. So sánh Playwright, Selenium và Cypress — bạn chọn công cụ nào?

Không có công cụ “tốt nhất” tuyệt đối, chọn theo bài toán. Playwright đang lên nhanh nhờ cross-browser mặc định, auto-waiting và xử lý iframe/shadow DOM tốt; Selenium mạnh về hệ sinh thái & legacy; Cypress dễ debug cho ứng dụng web hiện đại.

Mẹo ghi điểm: Nhà tuyển dụng 2026 hay hỏi sâu: “Suite test chạy 45 phút, làm sao rút xuống dưới 15 phút?” — trả lời bắt đầu từ chạy song song (parallelization) nhiều luồng/container.

3. Shift-left và shift-right testing là gì?

Shift-left là đưa kiểm thử lên sớm ngay từ giai đoạn phân tích/thiết kế để bắt lỗi từ đầu; shift-right là tiếp tục theo dõi chất lượng sau khi phát hành bằng dữ liệu người dùng thật & giám sát production. Kết hợp cả hai giúp giảm lỗi lọt ra production.

4. Bạn hiểu gì về kiểm thử trong CI/CD?

Trong CI/CD, test tự động được tích hợp vào pipeline (Jenkins, GitLab CI, GitHub Actions) và chạy tự động mỗi khi có commit/build — biến kiểm thử thành “cổng chất lượng” liên tục thay vì một bước tách rời cuối dự án (khái niệm QAOps).