# Bộ Câu Hỏi Luyện Phỏng Vấn Tester Junior

## Hướng Dẫn Sử Dụng

- Đọc câu hỏi, tự trả lời trước khi xem gợi ý
- Gợi ý chỉ là khung sườn — hãy thêm ví dụ cá nhân để câu trả lời sống động hơn
- Luyện nói to, không chỉ đọc thầm
- Thời gian mục tiêu mỗi câu: 1–2 phút

---

## PHẦN 1 — KIẾN THỨC CƠ BẢN
### 10 câu về khái niệm nền tảng

---

**Câu 1: Smoke Testing là gì? Khi nào bạn thực hiện nó?**

> 🎯 Gợi ý trả lời:
>
> Smoke Testing là bài kiểm tra nhanh để xác định xem bản build mới có đủ ổn định để tiến hành kiểm thử sâu hơn không. Giống như bật công tắc điện — nếu không cháy khói, mới tiếp tục dùng.
>
> **Khi nào thực hiện:** Ngay sau khi nhận build mới từ đội dev, trước khi bắt đầu regression hay functional testing.
>
> **Ví dụ thực tế:** App mới build xong → mở app được không, đăng nhập được không, vào được màn hình chính không. Nếu 3 bước này fail → trả lại dev ngay, không cần test tiếp.

---

**Câu 2: Regression Testing là gì? Tại sao nó quan trọng?**

> 🎯 Gợi ý trả lời:
>
> Regression Testing là kiểm thử lại các tính năng cũ sau khi có thay đổi code mới, để đảm bảo những thứ đang chạy tốt không bị hỏng vì sửa đổi mới.
>
> **Tại sao quan trọng:** Dev sửa bug A có thể vô tình làm hỏng feature B — điều này gọi là "regression". Tester phải bắt được điều này trước khi release.
>
> **Ví dụ:** Dev sửa chức năng thanh toán → Tester phải test lại cả đăng nhập, giỏ hàng, lịch sử đơn hàng dù những phần đó không được chỉnh sửa.

---

**Câu 3: Phân biệt Severity và Priority. Cho ví dụ cụ thể.**

> 🎯 Gợi ý trả lời:
>
> | | Severity | Priority |
> |---|---|---|
> | **Là gì** | Mức độ ảnh hưởng kỹ thuật của bug | Mức độ cần sửa gấp về mặt kinh doanh |
> | **Ai quyết định** | Tester/QA | Product Manager/Business |
>
> **Ví dụ 1 — High Severity, Low Priority:**
> Lỗi crash app khi người dùng nhập ký tự đặc biệt vào ô tìm kiếm bằng tiếng Klingon (ngôn ngữ không ai dùng). Lỗi nghiêm trọng về kỹ thuật nhưng không cần sửa gấp.
>
> **Ví dụ 2 — Low Severity, High Priority:**
> Logo công ty bị hiển thị sai màu trên trang chủ trong ngày ra mắt sản phẩm. Về kỹ thuật không nghiêm trọng nhưng phải sửa ngay vì ảnh hưởng thương hiệu.

---

**Câu 4: Một test case hoàn chỉnh gồm những phần nào?**

> 🎯 Gợi ý trả lời:
>
> Một test case chuẩn gồm các phần sau:
>
> - **Test Case ID** — mã định danh duy nhất (VD: TC_LOGIN_001)
> - **Title/Tên** — mô tả ngắn mục đích test
> - **Precondition** — điều kiện cần có trước khi test (VD: đã có tài khoản, đang ở màn hình login)
> - **Test Steps** — các bước thực hiện chi tiết, theo thứ tự
> - **Test Data** — dữ liệu đầu vào cụ thể
> - **Expected Result** — kết quả mong đợi
> - **Actual Result** — kết quả thực tế (điền sau khi test)
> - **Status** — Pass / Fail / Blocked / Skip
>
> **Mẹo nhớ:** Nếu người khác đọc test case của bạn mà thực hiện được y hệt và hiểu ngay — đó là test case tốt.

---

**Câu 5: Viết bug report như thế nào cho chuẩn?**

> 🎯 Gợi ý trả lời:
>
> Bug report tốt cần đủ để dev tái hiện lỗi mà không cần hỏi thêm. Các trường cần có:
>
> - **Bug ID & Title** — ngắn gọn, mô tả đúng vấn đề
> - **Environment** — thiết bị, OS, phiên bản app, browser
> - **Steps to Reproduce** — từng bước cụ thể để tái hiện lỗi
> - **Expected Result** — đúng ra phải xảy ra gì
> - **Actual Result** — thực tế xảy ra gì
> - **Severity & Priority**
> - **Screenshot/Video** — bằng chứng trực quan
> - **Log (nếu có)**
>
> **Ví dụ title tệ:** "App bị lỗi"
> **Ví dụ title tốt:** "[iOS 16 - App v2.3] Crash app khi nhấn nút Thanh toán với giỏ hàng trống"

---

**Câu 6: Black Box Testing và White Box Testing khác nhau như thế nào?**

> 🎯 Gợi ý trả lời:
>
> **Black Box Testing:**
> - Tester không biết code bên trong
> - Chỉ test dựa trên input và output
> - Giống người dùng thật sử dụng sản phẩm
> - Tester junior thường làm loại này
>
> **White Box Testing:**
> - Tester biết code, logic bên trong
> - Test các nhánh code, điều kiện cụ thể
> - Thường do dev tự test hoặc tester có kỹ năng code
>
> **Analogy dễ nhớ:** Black Box = lái xe không cần biết động cơ hoạt động thế nào. White Box = thợ máy kiểm tra từng bộ phận bên trong.

---

**Câu 7: Equivalence Partitioning và Boundary Value Analysis là gì? Tại sao dùng?**

> 🎯 Gợi ý trả lời:
>
> Đây là 2 kỹ thuật thiết kế test case giúp chọn dữ liệu test thông minh thay vì test tất cả mọi thứ.
>
> **Equivalence Partitioning (Phân vùng tương đương):**
> Chia input thành các nhóm có hành vi tương tự. Chỉ cần test 1 giá trị đại diện cho mỗi nhóm.
>
> **Boundary Value Analysis (Phân tích giá trị biên):**
> Test các giá trị ở ranh giới vì lỗi hay xuất hiện ở đó nhất.
>
> **Ví dụ:** Ô nhập tuổi hợp lệ từ 18–60
> - Valid: 18, 39, 60
> - Invalid: 17, 61, -1, 0
> - Boundary: 17, 18, 19 và 59, 60, 61

---

**Câu 8: Test Plan và Test Case khác nhau như thế nào?**

> 🎯 Gợi ý trả lời:
>
> **Test Plan** — Tài liệu chiến lược, trả lời câu hỏi **"Test cái gì, ai test, khi nào, bằng cách nào?"**
> - Scope (phạm vi test)
> - Approach (phương pháp)
> - Resources (nhân lực, công cụ)
> - Timeline
> - Risk
>
> **Test Case** — Tài liệu chiến thuật, trả lời câu hỏi **"Test bước nào cụ thể?"**
> - Hướng dẫn từng bước thực hiện một kịch bản cụ thể
>
> **Analogy:** Test Plan = bản đồ cả chuyến đi. Test Case = hướng dẫn từng ngã rẽ cụ thể.

---

**Câu 9: Vòng đời của một bug (Bug Life Cycle) là gì?**

> 🎯 Gợi ý trả lời:
>
> ```
> New → Assigned → In Progress → Fixed → Re-testing → Closed
>                                              ↓
>                                           Reopen (nếu vẫn lỗi)
> ```
>
> **Chi tiết từng trạng thái:**
> - **New** — Tester tìm thấy và report
> - **Assigned** — Lead/PM giao cho dev
> - **In Progress** — Dev đang sửa
> - **Fixed** — Dev báo đã sửa xong
> - **Re-testing** — Tester kiểm tra lại
> - **Closed** — Tester xác nhận pass
> - **Reopen** — Tester test lại vẫn fail → trả về cho dev
> - **Rejected** — Dev cho rằng không phải bug (cần thảo luận)
> - **Deferred** — Hoãn sửa sang sprint sau

---

**Câu 10: Sự khác nhau giữa Verification và Validation?**

> 🎯 Gợi ý trả lời:
>
> **Verification — "Build the product right?"**
> Kiểm tra xem sản phẩm có được xây dựng đúng theo đặc tả không.
> Thường là review tài liệu, code review, không cần chạy phần mềm.
>
> **Validation — "Build the right product?"**
> Kiểm tra xem sản phẩm có đáp ứng nhu cầu thực sự của người dùng không.
> Thường là chạy thực tế, UAT (User Acceptance Testing).
>
> **Ví dụ dễ hiểu:**
> - Verification: Xe máy được lắp đúng theo bản vẽ kỹ thuật không?
> - Validation: Xe máy này có phù hợp để đi trong phố không?

---

## PHẦN 2 — TÌNH HUỐNG THỰC TẾ
### 10 câu tình huống hay gặp

---

**Câu 11: Deadline release ngày mai, bạn vừa tìm thấy bug nghiêm trọng. Bạn làm gì?**

> 🎯 Gợi ý trả lời:
>
> **Bước 1 — Xác nhận bug:** Tái hiện lại ngay để chắc chắn không phải lỗi môi trường.
>
> **Bước 2 — Đánh giá impact:** Bug này ảnh hưởng đến bao nhiêu người dùng? Flow nào bị block?
>
> **Bước 3 — Báo cáo ngay, không chờ:** Report lên Jira/tool và báo trực tiếp cho lead/PM — đừng giấu vì sợ.
>
> **Bước 4 — Đề xuất phương án:**
> - Option A: Delay release để sửa bug
> - Option B: Release có bug nhưng ghi nhận risk rõ ràng
> - Option C: Workaround tạm thời cho người dùng
>
> **Bước 5 — Để người có thẩm quyền quyết định.** Tester không tự quyết định release hay không.
>
> **Điểm mấu chốt:** Nhiệm vụ của tester là cung cấp thông tin đầy đủ và kịp thời. Quyết định cuối cùng là của PM/Stakeholder.

---

**Câu 12: Dev nói "Đây không phải bug, đây là feature." Bạn phản hồi thế nào?**

> 🎯 Gợi ý trả lời:
>
> **Đừng tranh cãi cảm tính — dùng tài liệu để nói chuyện.**
>
> **Bước 1:** Bình tĩnh hỏi lại: "Anh/chị có thể chỉ cho em phần nào trong requirement/AC mô tả hành vi này không?"
>
> **Bước 2:** Nếu requirement nói hành vi phải khác → đây là bug, có bằng chứng rõ ràng.
>
> **Bước 3:** Nếu requirement không rõ hoặc không đề cập → leo thang lên BA/PM để làm rõ.
>
> **Bước 4:** Ghi nhận thảo luận, không bỏ qua.
>
> **Thái độ cần có:** Không phải "tôi đúng, anh sai" mà là "cùng nhau hiểu đúng requirement để ship sản phẩm tốt cho user."
>
> **Câu hay dùng:** *"Em hiểu anh có thể đúng, nhưng để chắc chắn mình cùng confirm lại với PM được không? Tránh để sau release user phàn nàn."*

---

**Câu 13: Bạn không đủ thời gian test hết tất cả. Bạn ưu tiên test phần nào?**

> 🎯 Gợi ý trả lời:
>
> Đây là câu hỏi về **Risk-Based Testing** — test thông minh thay vì test nhiều.
>
> **Tiêu chí ưu tiên:**
>
> 1. **Critical user flows** — Những gì user làm nhiều nhất (login, checkout, search)
> 2. **Phần mới thay đổi** — Code mới = risk cao nhất
> 3. **Phần từng có bug** — Bug hay tái phát ở chỗ cũ
> 4. **High business impact** — Tính năng liên quan tiền, bảo mật, dữ liệu
> 5. **Smoke test trước** — Đảm bảo core functions hoạt động
>
> **Điều quan trọng:** Báo với lead/PM về những gì **không** được test để họ nắm risk. Đừng im lặng.

---

**Câu 14: Viết test case cho chức năng Login tại chỗ. (Happy path + Negative cases)**

> 🎯 Gợi ý trả lời:
>
> **Happy Path (Positive):**
> - Đăng nhập với email và password hợp lệ → vào được màn hình chính
>
> **Negative Cases:**
> - Email đúng, password sai → hiện thông báo lỗi, không đăng nhập
> - Email sai format (thiếu @) → hiện lỗi ngay ở field
> - Cả 2 field để trống → hiện yêu cầu nhập
> - Email chưa đăng ký → thông báo "tài khoản không tồn tại"
> - Password đúng sai 5 lần liên tiếp → khóa tài khoản tạm thời
>
> **Edge Cases:**
> - Password có ký tự đặc biệt (@#$%)
> - Email có chữ hoa (TEST@gmail.com)
> - Copy-paste password
> - Đăng nhập khi mất mạng
> - Nhấn Enter thay vì click button
>
> **Mẹo khi làm tại chỗ:** Nói to suy nghĩ của bạn — interviewer muốn thấy tư duy, không chỉ kết quả.

---

**Câu 15: Bạn tìm thấy bug nhưng không thể tái hiện lại (intermittent bug). Bạn làm gì?**

> 🎯 Gợi ý trả lời:
>
> Bug không tái hiện được không có nghĩa là không có bug!
>
> **Các bước xử lý:**
>
> 1. **Ghi lại mọi thứ ngay lúc thấy:** Screenshot, video, log, bước đã làm trước đó
> 2. **Thử tái hiện nhiều lần** với các điều kiện khác nhau: mạng yếu/mạnh, xóa cache, thiết bị khác
> 3. **Kiểm tra điều kiện đặc biệt:** Múi giờ, ngôn ngữ, dung lượng pin thấp, background app
> 4. **Report bug với tag "Intermittent"** kèm theo bằng chứng đã có
> 5. **Không bỏ qua** — Intermittent bugs thường là race condition hoặc memory leak, rất nguy hiểm
>
> **Câu báo cáo mẫu:** *"Em gặp lỗi này 2 lần nhưng chưa tái hiện được ổn định. Em đã đính kèm video và log. Có thể là race condition — cần dev xem log để confirm."*

---

**Câu 16: QA team chỉ có mình bạn, dự án lớn, deadline gấp. Bạn quản lý công việc thế nào?**

> 🎯 Gợi ý trả lời:
>
> **Bước 1 — Hiểu scope rõ ràng:**
> - Bao nhiêu features cần test?
> - Feature nào critical nhất?
> - Timeline cụ thể ra sao?
>
> **Bước 2 — Tạo test plan đơn giản:**
> Liệt kê features, ước tính thời gian, xác định risk
>
> **Bước 3 — Communicate với lead/PM:**
> *"Với timeline này, em có thể cover A, B, C đầy đủ. Còn D và E em chỉ smoke test được. Mình chấp nhận risk này không?"*
>
> **Bước 4 — Test theo priority**
> High → Medium → Low
>
> **Bước 5 — Không ôm đồm một mình:**
> Đề xuất dev tự test phần của họ, nhờ BA review acceptance criteria
>
> **Thái độ cần thể hiện:** Chủ động, có hệ thống, biết communicate risk — không phải cố làm tất cả một mình rồi kiệt sức.

---

**Câu 17: Bạn làm thế nào khi nhận requirement không rõ ràng?**

> 🎯 Gợi ý trả lời:
>
> **Đây là tình huống cực kỳ phổ biến — đừng tự đoán!**
>
> **Bước 1:** Đọc kỹ tài liệu hiện có, ghi ra tất cả điểm chưa rõ
>
> **Bước 2:** Hỏi đúng người — BA hoặc PM, không hỏi dev về requirement
>
> **Bước 3:** Đặt câu hỏi cụ thể, không hỏi chung chung
> - ❌ "Requirement này không rõ"
> - ✅ "Nếu user chưa verify email mà cố login, hệ thống xử lý thế nào?"
>
> **Bước 4:** Ghi lại câu trả lời, update vào test case
>
> **Bước 5:** Nếu hỏi không được trong thời gian ngắn → test theo cả 2 cách có thể hiểu, note rõ assumption
>
> **Câu hay dùng:** *"Em hiểu requirement này có thể hiểu theo 2 cách: A hoặc B. Anh/chị có thể confirm mình muốn behavior nào không?"*

---

**Câu 18: Bạn nhận build mới nhưng không có tài liệu, không có requirement. Bạn làm gì?**

> 🎯 Gợi ý trả lời:
>
> Tình huống hay gặp ở startup hoặc team nhỏ — tester phải linh hoạt.
>
> **Bước 1:** Hỏi nhanh dev/PM: "Build này thay đổi gì so với version trước?"
>
> **Bước 2:** Xem changelog, commit message, ticket Jira (nếu có)
>
> **Bước 3:** Dùng **Exploratory Testing** — khám phá app như người dùng thật
>
> **Bước 4:** Đặt câu hỏi dựa trên common sense:
> - App này dùng để làm gì?
> - User chính là ai?
> - Flow quan trọng nhất là gì?
>
> **Bước 5:** Ghi lại những gì mình test để tạo thành tài liệu luôn
>
> **Thể hiện điểm mạnh:** Không bị động, biết tự tìm thông tin và tạo ra tài liệu từ đầu.

---

**Câu 19: Bạn phát hiện bug nhưng lead nói "nhỏ quá, không cần report." Bạn làm gì?**

> 🎯 Gợi ý trả lời:
>
> **Tình huống cần balance giữa tuân thủ và trách nhiệm nghề nghiệp.**
>
> **Bước 1:** Tôn trọng quyết định của lead trong lần đầu tiên
>
> **Bước 2:** Nếu không đồng ý, trình bày quan điểm một lần một cách chuyên nghiệp:
> *"Em hiểu ý lead, nhưng em lo ngại bug này có thể ảnh hưởng đến [X] trong trường hợp [Y]. Mình có thể log với priority thấp để track không ạ?"*
>
> **Bước 3:** Nếu lead vẫn từ chối → ghi chú cá nhân, tôn trọng quyết định
>
> **Bước 4:** Nếu bug sau này gây vấn đề lớn → đây là học bài về việc argue quan điểm đúng lúc
>
> **Điểm mấu chốt:** Tester không phải cảnh sát bug. Biết chọn trận đánh quan trọng, không nhất quyết report tất cả mọi thứ.

---

**Câu 20: User report bug trên production mà team đã test nhưng không thấy. Bạn cảm thấy thế nào và xử lý thế nào?**

> 🎯 Gợi ý trả lời:
>
> **Phản ứng đúng — không đổ lỗi, không phòng thủ:**
>
> **Ngắn hạn:**
> - Thu thập thông tin: thiết bị của user, bước tái hiện, tần suất
> - Cố tái hiện trên môi trường tương tự của user
> - Nếu confirm bug → report, fix nhanh
>
> **Phân tích nguyên nhân:**
> - Test case có cover scenario này không?
> - Test data có represent đúng data thật không?
> - Môi trường test có khác production không?
>
> **Dài hạn — Học từ sai:**
> - Update/thêm test case cho scenario này
> - Cải thiện test coverage
> - Có thể cân nhắc testing trên real device/real data
>
> **Thái độ cần thể hiện:** Trưởng thành, học từ kinh nghiệm, không tự ti nhưng cũng không phủ nhận. Testing không bao giờ đảm bảo 100% zero bug.

---

## PHẦN 3 — CÂU HỎI VỀ KINH NGHIỆM TRÁI NGÀNH
### 10 câu dành riêng cho người chuyển ngành

---

**Câu 21: Tại sao bạn chuyển sang ngành IT/Testing sau khi làm [ngành khác]?**

> 🎯 Gợi ý trả lời:
>
> **Cấu trúc trả lời: Kéo + Đẩy + Kết nối**
>
> - **Đẩy (Push):** Lý do rời ngành cũ — hãy trung thực nhưng tích cực, tránh phàn nàn
> - **Kéo (Pull):** Điều gì hấp dẫn bạn về Testing/IT
> - **Kết nối (Bridge):** Kỹ năng từ ngành cũ áp dụng được thế nào
>
> **Ví dụ (từ kế toán sang Tester):**
> *"Em làm kế toán 3 năm và nhận ra mình rất thích tìm sai số, kiểm tra con số. Khi tiếp xúc với phần mềm kế toán, em bắt đầu tò mò tại sao phần mềm lại hoạt động thế này, thế kia. Em tự học testing và nhận ra đây là nghề kết hợp được tư duy chi tiết của kế toán và sự tò mò với công nghệ."*
>
> **Tránh nói:** "Nghe nói IT lương cao" hoặc "Ngành cũ không có tương lai"

---

**Câu 22: Bạn có kinh nghiệm gì liên quan đến testing dù không làm IT?**

> 🎯 Gợi ý trả lời:
>
> **Gợi ý các transferable experiences theo ngành:**
>
> **Từ kế toán/tài chính:**
> Kiểm tra sai số, đối chiếu số liệu, attention to detail trong báo cáo
>
> **Từ giáo viên:**
> Soạn bài kiểm tra (như viết test case), phân tích lỗi của học sinh có hệ thống
>
> **Từ chăm sóc khách hàng:**
> Hiểu user pain points, biết cách mô tả vấn đề rõ ràng, nhẫn nại
>
> **Từ y tế/điều dưỡng:**
> Quy trình nghiêm ngặt, ghi chép chính xác, xử lý tình huống có áp lực
>
> **Từ bán hàng:**
> Hiểu user journey, test từ góc nhìn khách hàng thật
>
> **Câu gốc cần nhớ:** Testing không chỉ là biết code — là tư duy phản biện, sự tỉ mỉ, và hiểu user. Những thứ này có từ nhiều ngành nghề khác.

---

**Câu 23: Bạn đã tự học Testing như thế nào? Học từ đâu?**

> 🎯 Gợi ý trả lời:
>
> **Hãy kể hành trình học thật của bạn — cụ thể, không chung chung**
>
> **Cấu trúc gợi ý:**
> - Bắt đầu từ đâu? (Khóa học, sách, YouTube, forum)
> - Học được gì? (Kiến thức, tools)
> - Áp dụng như thế nào? (Project thực hành, side project)
> - Còn thiếu gì và đang bổ sung ra sao?
>
> **Ví dụ:**
> *"Em bắt đầu từ khóa Software Testing của ISTQB Foundation trên Udemy. Song song đó em đọc sách 'Lessons Learned in Software Testing'. Em thực hành bằng cách test các app thật như Shopee, Grab và viết bug report giả định. Em cũng tham gia cộng đồng Test Tribe Vietnam để học từ kinh nghiệm thực tế của mọi người."*
>
> **Bonus điểm:** Nếu bạn có portfolio bug reports, test cases — hãy đề cập và mang theo.

---

**Câu 24: Bạn có portfolio hoặc project thực hành nào chưa?**

> 🎯 Gợi ý trả lời:
>
> **Nếu CÓ:** Trình bày cụ thể — test app gì, viết bao nhiêu test case, tìm được bao nhiêu bug, dùng tool gì
>
> **Nếu CHƯA CÓ — Đừng nói "chưa có gì":**
>
> *"Em chưa có project thực tế nhưng em đã tự thực hành bằng cách:*
> - *Test app [tên app] và viết test cases theo chuẩn*
> - *Tìm bugs trên các website public và document lại*
> - *Thực hành viết bug report với screenshot và steps rõ ràng*
>
> *Em có thể show portfolio nhỏ này nếu anh/chị muốn xem."*
>
> **Lời khuyên thật:** Trước buổi phỏng vấn, hãy test một app và viết sẵn 5-10 test cases + 2-3 bug reports. Đó là portfolio tối thiểu chấp nhận được.

---

**Câu 25: Điểm mạnh nào từ ngành cũ giúp ích cho bạn khi làm Tester?**

> 🎯 Gợi ý trả lời:
>
> **Đây là câu bạn nên chuẩn bị kỹ nhất — là cơ hội biến "điểm yếu" thành lợi thế**
>
> **Framework trả lời: Kỹ năng + Ví dụ cụ thể + Áp dụng vào Testing**
>
> **Ví dụ 1 (từ nhân viên CSKH):**
> *"Làm CSKH 2 năm giúp em hiểu người dùng nghĩ gì và gặp vấn đề gì khi dùng sản phẩm. Em có thể test từ đúng góc nhìn của user thật, không chỉ từ góc nhìn kỹ thuật."*
>
> **Ví dụ 2 (từ giáo viên):**
> *"Soạn đề thi đòi hỏi thiết kế câu hỏi bao phủ nhiều tình huống khác nhau — rất giống viết test case. Em cũng quen làm việc có hệ thống và giải thích vấn đề rõ ràng."*
>
> **Ví dụ 3 (từ kỹ sư xây dựng):**
> *"Kỹ sư xây dựng kiểm tra vật liệu, công trình theo tiêu chuẩn nghiêm ngặt. Tư duy kiểm tra chất lượng có hệ thống đó rất tương đồng với QA."*

---

**Câu 26: Bạn dự kiến cần bao lâu để làm việc độc lập được?**

> 🎯 Gợi ý trả lời:
>
> **Trả lời thực tế, không nói "em học nhanh lắm" chung chung:**
>
> *"Em hiểu sẽ có learning curve khi bắt đầu. Em dự kiến:*
>
> *Tuần 1-2: Tìm hiểu product, codebase cơ bản, quy trình của team*
> *Tuần 3-4: Có thể thực hiện test cases có sẵn dưới sự hướng dẫn*
> *Tháng 2: Bắt đầu viết test case độc lập cho features đơn giản*
> *Tháng 3: Có thể đóng góp vào sprint planning và estimate*
>
> *Em sẽ chủ động hỏi khi không rõ và không chờ ai nói mới hỏi."*
>
> **Điểm cộng:** Cho thấy bạn tự nhận thức được giới hạn của mình và có kế hoạch cụ thể.

---

**Câu 27: Bạn sẽ làm gì nếu không hiểu thuật ngữ kỹ thuật trong team?**

> 🎯 Gợi ý trả lời:
>
> **Thể hiện thái độ proactive và không ngại hỏi:**
>
> *"Trước hết em sẽ tự tra cứu — Google, documentation, Stack Overflow. Nếu vẫn không hiểu sau 15-20 phút, em sẽ hỏi đồng nghiệp hoặc lead thay vì mất thời gian mãi.*
>
> *Em sẽ hỏi cụ thể: 'Anh/chị có thể giải thích [thuật ngữ X] trong context của hệ thống mình đang làm không?' — hỏi thế này đỡ mất thời gian hơn hỏi định nghĩa chung.*
>
> *Em cũng sẽ giữ một file note riêng cho team-specific terms để không hỏi lại cùng một thứ."*
>
> **Thái độ cần tránh:** Ngại hỏi vì sợ bị cho là ngốc, hoặc giả vờ hiểu rồi làm sai.

---

**Câu 28: Mức lương kỳ vọng của bạn với vai trò Tester Junior không có kinh nghiệm?**

> 🎯 Gợi ý trả lời:
>
> **Đây là câu không có đáp án cứng — nhưng có cách trả lời thông minh:**
>
> **Option 1 — Để nhà tuyển dụng offer trước:**
> *"Em chưa có kinh nghiệm thực tế trong ngành IT nên em muốn nghe mức công ty đang có cho vị trí này. Em sẵn sàng thương lượng dựa trên scope công việc và lộ trình phát triển."*
>
> **Option 2 — Đưa ra range có research:**
> *"Dựa trên research của em về thị trường, junior tester ở [thành phố] thường trong khoảng X-Y triệu. Em kỳ vọng trong khoảng này nhưng sẵn sàng linh hoạt tùy thuộc vào cơ hội học hỏi."*
>
> **Lưu ý:** Research trước bằng cách xem ITviec, TopCV, Vietnamworks để biết range thực tế.

---

**Câu 29: Kế hoạch 1-2 năm tới của bạn trong ngành Testing là gì?**

> 🎯 Gợi ý trả lời:
>
> **Thể hiện tham vọng có chừng mực và định hướng rõ ràng:**
>
> *"Trong 6 tháng đầu, em muốn nắm vững manual testing, hiểu product và quy trình của team.*
>
> *Năm đầu, em muốn bắt đầu học automation testing cơ bản — ít nhất 1 tool như Selenium hoặc Cypress — vì em thấy đây là hướng phát triển tất yếu.*
>
> *Năm 2, em muốn có thể đóng góp vào automation framework của team và có thể thi chứng chỉ ISTQB Foundation.*
>
> *Về dài hạn, em chưa chắc sẽ đi sâu vào performance testing, security testing hay API testing — em muốn để kinh nghiệm thực tế định hướng thêm."*
>
> **Tránh nói:** "Em muốn lên manager trong 2 năm" (quá nhanh) hoặc "Em chưa nghĩ đến" (thiếu định hướng)

---

**Câu 30: Bạn có câu hỏi gì cho chúng tôi không?**

> 🎯 Gợi ý trả lời:
>
> **ĐỪNG BAO GIỜ nói "Dạ không ạ" — đây là cơ hội vàng để thể hiện sự quan tâm thật sự**
>
> **Câu hỏi tốt về công việc:**
> - *"Một ngày làm việc thông thường của Tester Junior trong team anh/chị trông như thế nào?"*
> - *"Team hiện tại đang dùng tool và quy trình gì cho testing?"*
> - *"Người tester mà team đang tìm kiếm sẽ thay thế vị trí cũ hay là vị trí mới?"*
>
> **Câu hỏi về phát triển:**
> - *"Team có mentoring program hoặc cơ chế support cho người mới không?"*
> - *"Tester thường mất bao lâu để được giao công việc độc lập?"*
>
> **Câu hỏi về team/môi trường:**
> - *"Điều gì khiến anh/chị thích làm việc ở đây nhất?"*
>
> **Câu hỏi không nên hỏi sớm:**
> - Lương, thưởng, ngày phép (nếu chưa được đề cập)
> - "Công ty có stable không?" (nghe thiếu tự tin)

---

## BẢNG TÓM TẮT — CHECKLIST ÔN TẬP

| Nhóm | Câu | Trạng thái |
|------|-----|------------|
| **Kiến thức cơ bản** | Smoke vs Regression | ☐ |
| | Severity vs Priority | ☐ |
| | Test Case structure | ☐ |
| | Bug Report chuẩn | ☐ |
| | Black vs White Box | ☐ |
| | EP & BVA | ☐ |
| | Test Plan vs Test Case | ☐ |
| | Bug Life Cycle | ☐ |
| | Verification vs Validation | ☐ |
| **Tình huống** | Bug trước release | ☐ |
| | Conflict với dev | ☐ |
| | Ưu tiên test khi thiếu thời gian | ☐ |
| | Viết test case login | ☐ |
| | Intermittent bug | ☐ |
| | Solo QA dự án lớn | ☐ |
| | Requirement không rõ | ☐ |
| **Chuyển ngành** | Lý do chuyển ngành | ☐ |
| | Transferable skills | ☐ |
| | Hành trình tự học | ☐ |
| | Portfolio | ☐ |
| | Kế hoạch tương lai | ☐ |
| | Câu hỏi cho nhà tuyển dụng | ☐ |

---

## NGUYÊN TẮC VÀNG KHI TRẢ LỜI

> **1. Dùng cấu trúc STAR cho câu tình huống**
> Situation → Task → Action → Result
>
> **2. Luôn có ví dụ cụ thể**
> "Em nghĩ tester nên..." < "Khi tự học, em đã..."
>
> **3. Thừa nhận điểm yếu một cách có kiểm soát**
> "Em chưa có kinh nghiệm X, nhưng em đang học bằng cách Y"
>
> **4. Không nói xấu nơi cũ**
> Dù lý do chuyển ngành có tiêu cực — hãy frame tích cực
>
> **5. Hỏi lại nếu không hiểu câu hỏi**
> "Anh/chị có thể clarify thêm không ạ?" — Đây là tư duy của tester giỏi

---

*Tài liệu này dành cho mục đích luyện tập cá nhân. Câu trả lời tốt nhất là câu có ví dụ thật từ trải nghiệm của chính bạn.*