# 🧪 Bộ Câu Hỏi Ôn Tập Phỏng Vấn Fresher Tester > **Dành cho:** Người mới bắt đầu hoặc đang chuyển ngành sang QA/Testing > **Gồm:** 25 câu hỏi chia 4 nhóm | Gợi ý trả lời | Điểm cần tránh --- ## 📌 NHÓM 1: CÂU HỎI VỀ BẢN THÂN *Mục tiêu: Nhà tuyển dụng muốn hiểu động lực, tính cách và sự phù hợp của bạn với vị trí Tester* --- ### ❓ Câu 1: Tại sao bạn chọn vị trí Tester thay vì các vị trí IT khác? **💡 Gợi ý trả lời:** > Nên kết hợp lý do thực tế + tố chất cá nhân. Ví dụ: Bạn có tư duy logic, chú ý chi tiết và thích tìm lỗi hệ thống. Bạn nhận ra rằng Tester đóng vai trò quan trọng trong việc bảo vệ trải nghiệm người dùng. Nếu chuyển ngành, hãy nêu kỹ năng từ ngành cũ có thể áp dụng (ví dụ: kế toán → tư duy cẩn thận, chính xác). **⚠️ Điểm cần tránh:** - ❌ Nói "vì Tester dễ hơn Dev" — nghe thiếu nghiêm túc - ❌ Không có lý do rõ ràng, trả lời mơ hồ kiểu "em thấy phù hợp" - ❌ Chỉ nói vì lương hoặc vì dễ xin việc --- ### ❓ Câu 2: Điểm mạnh của bạn phù hợp với vị trí Tester là gì? **💡 Gợi ý trả lời:** > Chọn 2–3 điểm mạnh liên quan trực tiếp đến Tester: tư duy phân tích, sự tỉ mỉ, khả năng đặt câu hỏi. Mỗi điểm nên có ví dụ minh họa cụ thể từ học tập hoặc công việc cũ. Ví dụ: "Em thường xuyên phát hiện lỗi nhỏ trong báo cáo kế toán mà người khác bỏ qua — đó là tư duy tester trong em." **⚠️ Điểm cần tránh:** - ❌ Liệt kê điểm mạnh chung chung như "em chăm chỉ, nhiệt tình" - ❌ Không có ví dụ thực tế đi kèm - ❌ Nêu quá nhiều điểm mạnh (loãng, thiếu thuyết phục) --- ### ❓ Câu 3: Điểm yếu của bạn là gì? Bạn đang cải thiện như thế nào? **💡 Gợi ý trả lời:** > Chọn một điểm yếu thật — nhưng không ảnh hưởng trực tiếp đến công việc Tester. Ví dụ: "Em đôi khi quá chú trọng chi tiết nên mất thêm thời gian — em đang học cách ưu tiên task theo mức độ quan trọng." Phải luôn có hành động cải thiện cụ thể đi kèm. **⚠️ Điểm cần tránh:** - ❌ Nói "em không có điểm yếu" — nghe không trung thực - ❌ Nêu điểm yếu nghiêm trọng ảnh hưởng trực tiếp đến công việc (ví dụ: "em hay bỏ sót chi tiết") - ❌ Không có kế hoạch cải thiện đi kèm --- ### ❓ Câu 4: Kỳ vọng của bạn về công việc này là gì? **💡 Gợi ý trả lời:** > Nên chia 2 phần: kỳ vọng về học hỏi & phát triển, và kỳ vọng về môi trường làm việc. Ví dụ: "Em kỳ vọng được làm việc trong môi trường có mentor hướng dẫn, được tham gia dự án thực tế để rèn kỹ năng viết test case và sử dụng công cụ như Jira. Về lâu dài, em muốn phát triển theo hướng QA Engineer." **⚠️ Điểm cần tránh:** - ❌ Chỉ nói về lương hoặc phúc lợi - ❌ Kỳ vọng quá cao so với vị trí fresher (ví dụ: muốn lead team ngay) - ❌ Không có định hướng nghề nghiệp rõ ràng --- ### ❓ Câu 5: Bạn biết gì về công ty chúng tôi? Tại sao muốn làm ở đây? **💡 Gợi ý trả lời:** > Cần chuẩn bị kỹ trước buổi phỏng vấn: tìm hiểu lĩnh vực, sản phẩm, văn hóa công ty. Kết nối thông tin đó với mục tiêu cá nhân. Ví dụ: "Em biết công ty đang phát triển ứng dụng fintech — đây là lĩnh vực em quan tâm vì kết hợp giữa tài chính và công nghệ, phù hợp với background của em." **⚠️ Điểm cần tránh:** - ❌ Không biết gì về công ty — cho thấy thiếu chuẩn bị - ❌ Trả lời chung chung kiểu "công ty có tiếng nên em muốn vào" - ❌ Chỉ nhắc đến lương thưởng --- ## 📚 NHÓM 2: KIẾN THỨC CƠ BẢN VỀ TESTING *Mục tiêu: Kiểm tra nền tảng lý thuyết — cần trả lời chính xác, ngắn gọn, có ví dụ* --- ### ❓ Câu 6: Test case là gì? Một test case cần có những thành phần nào? **💡 Gợi ý trả lời:** > Test case là tài liệu mô tả các bước kiểm thử một tính năng cụ thể, bao gồm: **Test Case ID, Tên test case, Điều kiện tiên quyết (Precondition), Các bước thực hiện (Steps), Dữ liệu đầu vào (Test Data), Kết quả mong đợi (Expected Result), Kết quả thực tế (Actual Result), Trạng thái (Pass/Fail).** Ví dụ: Test case cho chức năng đăng nhập với email hợp lệ. **⚠️ Điểm cần tránh:** - ❌ Nhầm test case với test plan hoặc test scenario - ❌ Thiếu các thành phần quan trọng (đặc biệt là Expected Result) - ❌ Không thể đưa ra ví dụ thực tế --- ### ❓ Câu 7: Bug là gì? Phân biệt Bug, Defect và Error. **💡 Gợi ý trả lời:** > **Error** là lỗi do con người (developer) gây ra trong quá trình viết code. **Defect (Bug)** là kết quả của lỗi đó tồn tại trong phần mềm — khi tester phát hiện ra. **Failure** xảy ra khi hệ thống không hoạt động đúng khi người dùng thực tế sử dụng. Trong thực tế, "bug" và "defect" thường được dùng thay thế nhau. **⚠️ Điểm cần tránh:** - ❌ Nói bug và lỗi là một — thiếu chiều sâu - ❌ Không phân biệt được 3 khái niệm - ❌ Không có ví dụ minh họa --- ### ❓ Câu 8: Mô tả Bug Life Cycle (Vòng đời của Bug). **💡 Gợi ý trả lời:** > Vòng đời bug gồm các trạng thái chính: **New → Assigned → Open → Fixed → Retest → Verified → Closed.** Ngoài ra còn có các nhánh: **Rejected** (không phải bug), **Duplicate** (đã tồn tại), **Deferred** (hoãn lại), **Reopened** (lỗi quay lại sau fix). Tester chịu trách nhiệm ở bước New, Retest, Verified và Closed. **⚠️ Điểm cần tránh:** - ❌ Chỉ nói được 3–4 trạng thái cơ bản - ❌ Không biết tester có vai trò gì trong vòng đời này - ❌ Nhầm thứ tự các trạng thái --- ### ❓ Câu 9: Phân biệt Functional Testing và Non-Functional Testing. Cho ví dụ. **💡 Gợi ý trả lời:** > **Functional Testing** kiểm tra xem phần mềm có hoạt động đúng theo yêu cầu không — ví dụ: đăng nhập, thêm vào giỏ hàng, thanh toán. **Non-Functional Testing** kiểm tra các yếu tố phi chức năng: hiệu suất (Performance), bảo mật (Security), khả năng tải (Load), tính dễ dùng (Usability). Ví dụ: Trang web có chịu được 10.000 người dùng cùng lúc không. **⚠️ Điểm cần tránh:** - ❌ Chỉ biết Functional Testing, không biết Non-Functional - ❌ Không thể đưa ra ví dụ cụ thể - ❌ Nhầm Performance Testing vào Functional --- ### ❓ Câu 10: Phân biệt Black-box, White-box và Grey-box Testing. **💡 Gợi ý trả lời:** > **Black-box:** Tester không biết code bên trong, chỉ test dựa trên input/output và yêu cầu — phù hợp với Functional Testing. **White-box:** Tester biết code, kiểm tra logic bên trong — thường do developer thực hiện. **Grey-box:** Kết hợp cả hai — tester biết một phần cấu trúc hệ thống để test hiệu quả hơn. Fresher Tester thường bắt đầu với Black-box Testing. **⚠️ Điểm cần tránh:** - ❌ Nhầm Black-box là "không cần biết gì" — vẫn cần hiểu requirement - ❌ Không biết loại nào phù hợp với vị trí mình ứng tuyển - ❌ Nhầm White-box testing chỉ do tester làm --- ### ❓ Câu 11: Regression Testing là gì? Khi nào cần thực hiện? **💡 Gợi ý trả lời:** > **Regression Testing** là kiểm thử lại các tính năng đã hoạt động tốt trước đó, nhằm đảm bảo các thay đổi mới (fix bug, thêm tính năng) không làm hỏng những gì đang chạy ổn định. Thực hiện sau mỗi lần có code thay đổi, đặc biệt trước khi release. Ví dụ: Sau khi fix bug đăng nhập, cần test lại toàn bộ luồng mua hàng. **⚠️ Điểm cần tránh:** - ❌ Nhầm với Retesting (retest chỉ kiểm tra đúng bug đã được fix) - ❌ Không biết khi nào cần thực hiện - ❌ Không phân biệt được Regression vs Retesting --- ### ❓ Câu 12: Smoke Testing và Sanity Testing khác nhau như thế nào? **💡 Gợi ý trả lời:** > **Smoke Testing** kiểm tra nhanh các chức năng cốt lõi nhất sau khi nhận build mới — như "thở" thử xem phần mềm có sống không. Nếu Smoke Test fail, trả lại build ngay. **Sanity Testing** kiểm tra sâu hơn vào một tính năng cụ thể vừa được fix hoặc thay đổi — thực hiện sau Smoke Test. Smoke = rộng & nông, Sanity = hẹp & sâu. **⚠️ Điểm cần tránh:** - ❌ Nhầm hoàn toàn hai khái niệm này - ❌ Không biết thứ tự thực hiện (Smoke trước, Sanity sau) - ❌ Giải thích quá dài dòng, thiếu rõ ràng --- ## 🛠️ NHÓM 3: KỸ NĂNG THỰC TẾ *Mục tiêu: Đánh giá khả năng làm việc thực chiến — hãy trả lời có cấu trúc và dẫn chứng cụ thể* --- ### ❓ Câu 13: Hãy viết test case cho chức năng đăng nhập cơ bản. **💡 Gợi ý trả lời:** > Cần bao phủ các kịch bản: ✅ Đăng nhập thành công (email + mật khẩu đúng), ❌ Sai mật khẩu, ❌ Sai email, ❌ Bỏ trống email hoặc mật khẩu, ❌ Email không đúng định dạng, ⚠️ Tài khoản bị khóa, ⚠️ Đăng nhập sau N lần sai liên tiếp. Mỗi case cần có: Steps rõ ràng, Expected Result cụ thể. Đây là câu hỏi thực hành — nên viết ra giấy trong lúc phỏng vấn. **⚠️ Điểm cần tránh:** - ❌ Chỉ viết happy path (đăng nhập thành công) — quá ít - ❌ Thiếu test case cho edge cases và negative cases - ❌ Expected Result mơ hồ như "hiện thông báo lỗi" (cần ghi rõ thông báo gì) --- ### ❓ Câu 14: Một bug report cần có những thông tin gì? **💡 Gợi ý trả lời:** > Một bug report chuẩn gồm: **Bug ID, Tiêu đề (ngắn gọn, rõ ràng), Môi trường (OS, browser, version), Bước tái hiện (Steps to Reproduce), Kết quả thực tế (Actual Result), Kết quả mong đợi (Expected Result), Mức độ nghiêm trọng (Severity), Độ ưu tiên (Priority), Trạng thái, Ảnh chụp/video đính kèm.** Tiêu đề nên theo format: [Màn hình] + [Hành động] + [Kết quả lỗi]. **⚠️ Điểm cần tránh:** - ❌ Bug report thiếu Steps to Reproduce — dev không thể tái hiện - ❌ Tiêu đề mơ hồ như "Bị lỗi ở trang đăng nhập" - ❌ Không đính kèm bằng chứng (screenshot, video) --- ### ❓ Câu 15: Phân biệt Priority và Severity. Cho ví dụ kết hợp 4 trường hợp. **💡 Gợi ý trả lời:** > **Severity** = Mức độ ảnh hưởng kỹ thuật đến hệ thống (do Tester đánh giá). **Priority** = Mức độ cần xử lý nhanh về mặt kinh doanh (do PM/BA quyết định). 4 trường hợp: 🔴 High Severity + High Priority: Lỗi thanh toán không thực hiện được. 🟡 High Severity + Low Priority: Lỗi tính năng ít người dùng. 🟠 Low Severity + High Priority: Logo công ty hiển thị sai (ảnh hưởng thương hiệu). 🟢 Low Severity + Low Priority: Lỗi font chữ nhỏ ít ảnh hưởng. **⚠️ Điểm cần tránh:** - ❌ Nhầm Priority và Severity — đây là lỗi phổ biến nhất - ❌ Không thể đưa ra ví dụ 4 trường hợp kết hợp - ❌ Nói Severity do PM quyết định (sai — Tester đánh giá) --- ### ❓ Câu 16: Bạn đã dùng Jira chưa? Mô tả cách tạo một bug trên Jira. **💡 Gợi ý trả lời:** > Nếu đã dùng: Mô tả luồng tạo bug: Vào project → Create Issue → Chọn loại "Bug" → Điền Summary, Description (steps, actual, expected), Assign cho dev, chọn Priority, đính kèm file. Nếu chưa dùng thực tế: "Em đã tự học qua Jira demo, biết cách tạo issue, cập nhật trạng thái và theo dõi bug trên board Kanban/Scrum." **Không nên giả vờ đã có kinh nghiệm nếu chưa có.** **⚠️ Điểm cần tránh:** - ❌ Nói chưa dùng và không có gì để thêm — nên tự học trước phỏng vấn - ❌ Nói đã dùng nhưng không mô tả được chi tiết - ❌ Nhầm Jira với các công cụ khác (Trello, Notion) --- ### ❓ Câu 17: Equivalence Partitioning và Boundary Value Analysis là gì? Áp dụng vào ví dụ thực tế. **💡 Gợi ý trả lời:** > **Equivalence Partitioning (EP):** Chia dữ liệu đầu vào thành các nhóm tương đương, chỉ cần test 1 đại diện mỗi nhóm. **Boundary Value Analysis (BVA):** Test tại các giá trị biên (min, max, min-1, max+1). Ví dụ: Ô nhập tuổi hợp lệ 18–60. EP: Test 25 (hợp lệ), 10 (không hợp lệ), 70 (không hợp lệ). BVA: Test 17, 18, 19, 59, 60, 61. **⚠️ Điểm cần tránh:** - ❌ Không biết 2 kỹ thuật quan trọng này — được hỏi rất thường xuyên - ❌ Biết lý thuyết nhưng không áp dụng được vào ví dụ - ❌ BVA chỉ test đúng min và max, bỏ qua min±1, max±1 --- ### ❓ Câu 18: Agile/Scrum là gì? Tester có vai trò gì trong Scrum team? **💡 Gợi ý trả lời:** > **Agile** là phương pháp phát triển phần mềm linh hoạt, chia dự án thành các **Sprint** (thường 1–2 tuần). **Scrum** là framework phổ biến nhất của Agile. Trong Scrum team, Tester tham gia từ đầu Sprint: review requirement với BA, viết test case song song với dev, test trong Sprint, tham gia Daily Standup báo cáo tiến độ và blockers, và tham gia Sprint Review/Retrospective. **⚠️ Điểm cần tránh:** - ❌ Không biết Agile/Scrum — hầu hết công ty hiện nay dùng - ❌ Nghĩ Tester chỉ test cuối Sprint - ❌ Không biết các ceremony của Scrum (Daily, Sprint Planning, Retrospective) --- ## 🎯 NHÓM 4: CÂU HỎI TÌNH HUỐNG *Mục tiêu: Đánh giá tư duy xử lý vấn đề, soft skill và thái độ làm việc* --- ### ❓ Câu 19: Developer nói "đây không phải bug, đây là feature" — bạn xử lý thế nào? **💡 Gợi ý trả lời:** > Bước 1: Không tranh luận cảm tính. Bước 2: Quay lại **tài liệu requirement/spec** để đối chiếu — nếu behavior không đúng với requirement là bug. Bước 3: Nếu requirement mơ hồ, leo thang lên BA/PM để làm rõ. Bước 4: Ghi lại toàn bộ evidence (screenshot, log, tài liệu). Bước 5: Cập nhật trạng thái bug và để team quyết định. Nguyên tắc: dựa vào **tài liệu, không dựa vào cảm tính.** **⚠️ Điểm cần tránh:** - ❌ Tranh luận gay gắt với developer - ❌ Nhượng bộ ngay mà không có cơ sở - ❌ Tự quyết định mà không hỏi BA/PM khi requirement không rõ --- ### ❓ Câu 20: Bạn phát hiện bug nghiêm trọng nhưng deadline release chỉ còn 2 tiếng — bạn làm gì? **💡 Gợi ý trả lời:** > Bước 1: **Báo cáo ngay lập tức** cho Team Lead/PM — không tự quyết định. Bước 2: Cung cấp đầy đủ thông tin: mức độ nghiêm trọng, tần suất xảy ra, workaround có không. Bước 3: Team cùng quyết định: delay release, hotfix nhanh, hoặc release kèm known issue. Bước 4: Document lại quyết định. **Tester không tự quyết định release hay không — đó là trách nhiệm của PM.** **⚠️ Điểm cần tránh:** - ❌ Tự quyết định bỏ qua bug để release đúng hạn - ❌ Im lặng vì sợ ảnh hưởng đến deadline - ❌ Hoảng loạn và không hành động có cấu trúc --- ### ❓ Câu 21: Requirement rất mơ hồ, không rõ tính năng cần hoạt động như thế nào — bạn làm gì? **💡 Gợi ý trả lời:** > Bước 1: Đọc kỹ tài liệu hiện có, tham chiếu các tài liệu liên quan (wireframe, user story). Bước 2: Liệt kê danh sách các điểm chưa rõ thành câu hỏi cụ thể. Bước 3: Gặp trực tiếp BA/PO để làm rõ — không tự diễn giải. Bước 4: Sau khi có câu trả lời, cập nhật vào tài liệu để team cùng có cùng hiểu biết. Bước 5: Viết test case dựa trên requirement đã được làm rõ. **⚠️ Điểm cần tránh:** - ❌ Tự suy đoán rồi viết test case theo ý mình hiểu - ❌ Không hỏi vì sợ bị đánh giá là không hiểu - ❌ Bỏ qua và chờ đến khi test mới hỏi — quá muộn --- ### ❓ Câu 22: Bạn đang test một tính năng và liên tục gặp bug — build quá tệ, bạn làm gì? **💡 Gợi ý trả lời:** > Bước 1: Log tất cả bug tìm được đầy đủ và chi tiết. Bước 2: Đánh giá xem có nên tiếp tục test không — nếu bug quá nhiều ở tính năng cơ bản, có thể **reject build** và yêu cầu build mới. Bước 3: Báo cáo tình trạng lên Team Lead kèm theo số lượng bug và mức độ. Bước 4: Đề xuất dev fix critical bug trước khi tester tiếp tục. Smoke test failure = signal để stop testing sớm. **⚠️ Điểm cần tránh:** - ❌ Cố test hết dù build quá tệ — tốn thời gian vô ích - ❌ Không báo cáo, tự âm thầm xử lý - ❌ Reject build mà không có bằng chứng/lý do cụ thể --- ### ❓ Câu 23: Bạn bị áp lực phải test nhanh hơn, dẫn đến bỏ sót nhiều test case — bạn làm gì? **💡 Gợi ý trả lời:** > Bước 1: Áp dụng **Risk-based Testing** — ưu tiên test các tính năng quan trọng, tần suất sử dụng cao, rủi ro cao. Bước 2: Trao đổi với PM về scope test có thể giảm — nhưng phải rõ rủi ro kèm theo. Bước 3: Ghi lại những gì **không được test** để team biết rủi ro. Bước 4: Đề xuất tăng effort automation về lâu dài. **Tester có trách nhiệm nêu rủi ro — không im lặng chấp nhận rủi ro ẩn.** **⚠️ Điểm cần tránh:** - ❌ Im lặng chấp nhận và test qua loa - ❌ Từ chối không test vì không đủ thời gian - ❌ Không báo cáo rủi ro khi scope bị cắt giảm --- ### ❓ Câu 24: Bạn tìm thấy bug critical nhưng nó xảy ra ngẫu nhiên, không tái hiện được — bạn làm gì? **💡 Gợi ý trả lời:** > Bước 1: Ghi lại **ngay lúc đó** — screenshot, video, log, thông tin môi trường, dữ liệu đang dùng. Bước 2: Cố thử tái hiện nhiều lần với các điều kiện khác nhau. Bước 3: Log bug với status "Cannot Reproduce" nhưng đính kèm đầy đủ evidence. Bước 4: Nhờ dev xem log hệ thống để tìm nguyên nhân. Bước 5: Không bỏ qua — bug intermittent đôi khi là dấu hiệu vấn đề race condition nghiêm trọng. **⚠️ Điểm cần tránh:** - ❌ Không log vì "không tái hiện được" - ❌ Bỏ qua hoàn toàn vì nghĩ là do môi trường - ❌ Không thu thập evidence ngay khi thấy bug --- ### ❓ Câu 25: Nếu dev fix bug nhưng khi retest vẫn còn lỗi — quy trình xử lý của bạn là gì? **💡 Gợi ý trả lời:** > Bước 1: Retest đúng môi trường, đúng steps to reproduce đã ghi trong bug report. Bước 2: Nếu bug vẫn còn → **Reopen bug**, cập nhật Actual Result mới, comment rõ "Bug vẫn tồn tại sau fix ở build X." Bước 3: Thông báo cho dev biết kèm evidence. Bước 4: **Không xóa bug cũ tạo bug mới** — reopen chính bug đó để giữ lịch sử. Bước 5: Nếu bug đã fix nhưng có behavior mới khác → log bug mới riêng. **⚠️ Điểm cần tránh:** - ❌ Đóng bug khi chưa retest cẩn thận - ❌ Tạo bug mới thay vì reopen bug cũ (mất lịch sử) - ❌ Không ghi comment rõ ràng khi reopen --- ## 📝 BẢNG TỔNG HỢP NHANH | # | Nhóm | Câu hỏi | Từ khóa cần nhớ | |---|------|---------|-----------------| | 1–5 | 👤 Bản thân | Động lực, điểm mạnh/yếu, kỳ vọng | Cụ thể, có ví dụ, trung thực | | 6–12 | 📚 Kiến thức | Test case, Bug, Life cycle, Loại testing | Định nghĩa + phân biệt + ví dụ | | 13–18 | 🛠️ Thực tế | Viết test case, Bug report, Jira, Priority/Severity | Cấu trúc rõ, áp dụng được ngay | | 19–25 | 🎯 Tình huống | Xử lý conflict, deadline, ambiguous requirement | Bình tĩnh, có quy trình, báo cáo đúng người | --- ## 🚀 TIPS CUỐI CHO FRESHER TESTER > **✅ Trước phỏng vấn:** > - Tự tạo Jira account (có free plan) và thực hành tạo bug > - Luyện viết 10+ test case cho các app quen thuộc (Shopee, Grab, Zalo) > - Học thuộc Bug Life Cycle và vẽ sơ đồ > > **✅ Trong phỏng vấn:** > - Luôn kết hợp lý thuyết + ví dụ cụ thể > - Nếu không biết: thành thật + nói bạn sẽ học như thế nào > - Hỏi lại interviewer 1–2 câu về team/dự án — thể hiện sự quan tâm > > **✅ Tư duy cốt lõi của Tester:** > *"Tester không tìm bug để chỉ trích — Tester tìm bug để bảo vệ người dùng cuối."* --- *📅 Cập nhật lần cuối: 2025 | Phù hợp cho vị trí: QA Fresher, Manual Tester, Junior Tester*