Chuyển ngành vào tester: Cách viết CV, trả lời phỏng vấn và giải thích lý do chuyển nghề

3 tháng trước · 19 phút đọc

CV tester không có kinh nghiệm: cách viết để pass được HR

Công việc đầu tiên là CV. HR nhìn CV tester trái ngành, thường nghĩ: "Không làm test bao giờ, sao biết cái gì?" Bạn phải chứng minh là CÓ CẬP BỌ - từ những gì bạn làm ở công việc cũ hay dự án tự học.

344797 Cấu trúc CV tester không kinh nghiệm: focus vào kỹ năng chuyển đổi thay vì tuần tự công việc

Mấu chốt: KHÔNG liệt kê công việc cũ dài dòng. Thay vào đó, rút ra kỹ năng LIÊN QUAN tới testing - tỉ mỉ, logic, ghi chép, giao tiếp. Từ kế toán: kiểm tra chứng từ (audit mindset). Từ marketing: hiểu behavior user. Từ ngoại ngữ: đọc requirements bằng tiếng Anh. Từ điều dưỡng: tuân thủ quy trình, chính xác dữ liệu bệnh nhân.

Phần thông tin cơ bản: Tên, số điện thoại, email, GitHub (nếu có).

Phần mục tiêu nghề nghiệp: Viết 1-2 câu, TỎ RÕ bạn muốn vào testing. Ví dụ: "Muốn phát triển sự nghiệp tester, chuyên sâu vào test case, bug report, automation test. Tuy chưa làm tester chính thức, nhưng từ công việc kế toán, mình đã áp dụng tư duy kiểm tra kỹ, tìm sai sót." KHÔNG viết: "Tìm việc làm tester để có thu nhập cao" hay "Muốn thay đổi bản thân."

Phần kỹ năng: Liệt kê kỹ năng CÓ + CHUYỂN NGHÀNH:

Kỹ năng testing: Test case design, bug report, SQL cơ bản (nếu học), Postman (nếu học)
Kỹ năng chuyển nghề (rút ra từ công việc cũ): Attention to detail, analytical thinking, documentation, giao tiếp rõ ràng
Kỹ năng khác: Tiếng Anh (level nào), các tool (Jira, Excel...)

Phần kinh nghiệm: Nếu chưa làm tester, viết:

Công việc cũ: rút ra 2-3 điểm liên quan tới testing. Ví dụ từ kế toán: "Kiểm tra báo cáo tài chính hàng tháng, phát hiện sai sót số liệu." Từ marketing: "Test A/B campaign, phân tích kết quả."
Dự án tự học: viết rõ (nếu có). Ví dụ: "Thực hành viết test case cho trang đăng nhập với 10+ test scenarios." Chỗ nào học (online course, tự code, thực hành).

Phần dự án: Nếu chưa có dự án testing thực tế, viết dự án tự học hoặc thử thách nhỏ:

"Test case cho tính năng [tên] của [app]" - khoảng 5-10 test case
"Bug report mẫu" - ghi rõ cách viết formal
"Automation test với Selenium/Postman" - nếu học (ngay cả tutorial)

Mẹo CV: KHÔNG để CV trống ngoài kinh nghiệm. HR không thấy gì, không gọi phỏng vấn.

Tải mẫu CV tester không kinh nghiệm: Tải mẫu CV tester

Lý do chuyển ngành: câu trả lời thuyết phục cho HR

HR luôn hỏi: "Tại sao bạn lại bỏ [công việc cũ] để vào testing?" Câu trả lời này SIÊU QUAN TRỌNG. Nếu bạn nói "mình chán công việc cũ" hoặc "muốn kiếm tiền nhiều hơn", HR sẽ nghĩ bạn sẽ bỏ testing sau 3 tháng.

344798 So sánh cách trả lời: Tránh tránh bảo lộn, hãy nói rõ động lực thật

Mẫu trả lời tốt có 3 yếu tố:

1. Tính logic - TẠI SAO testing phù hợp?

Kohesion từ công việc cũ tới testing. Ví dụ:

Từ kế toán: "Kế toán liên quan tới kiểm tra kỹ, tìm lỗi. Testing cũng vậy - tìm bug qua test case. Mình thích cái tư duy 'check lại' này, và testing cho mình cơ hội chuyên sâu hơn."
Từ marketing: "Marketing cần hiểu user behavior, test campaign. Testing cũng phải hiểu user, design test scenario từ user perspective. Mình muốn chuyên vào phần này."
Từ ngoại ngữ: "Ngoại ngữ dạy mình đọc hiểu từng chi tiết, grammar, logic. Testing đòi hỏi cái tư duy 'detail-oriented' giống y hệt."
Từ điều dưỡng: "Điều dưỡng cần tuân thủ quy trình, không sai sót vì ảnh hưởng tới health người bệnh. Testing cũng vậy - 1 lỗi bỏ qua có thể crash hệ thống. Mình thích cái trách nhiệm này."

2. Tính chân thực - Bạn thực sự muốn?

Đừng nói "mình không có lựa chọn khác" hay "mình cần việc nên chọn testing." HR biết đó là dối. Thay vào đó:

"Mình học thêm test case, viết mẫu test case cho [app cụ thể], thấy thích phần này. Mình rõ ràng muốn theo đuổi."
"Mình tự học Postman, Jira, SQL cơ bản. Từ đó mình tin testing là đúng hướng cho mình."

3. Tính dài hạn - Bạn sẽ ở lâu?

HR sợ bạn sẽ bỏ sau 3 tháng. Trấn an họ:

"Mình lên kế hoạch dài hạn: đầu tiên là fresher tester, sau đó chuyên sâu vào automation test hoặc test lead. Mình sẵn sàng học thêm."

Mẫu trả lời đầy đủ:

"Từ công việc kế toán (hoặc marketing, ngoại ngữ...), mình nhận ra mình thích kiểm tra kỹ, tìm sai sót, đảm bảo quality. Testing phù hợp với tư duy này. Mình bắt đầu học test case, viết mẫu cho vài app, rồi nhận ra mình thực sự thích phần này hơn công việc trước. Mình không nhập cuộc để kiếm tiền, mà vì mình muốn chuyên sâu vào testing. Mình sẵn sàng học automation test, SQL, hoặc các kỹ năng khác để phát triển sự nghiệp dài hạn."

Câu này dài nhưng CHÂN THỰC. HR nghe được bạn biết mình muốn gì. Khi phỏng vấn, THƯỜNG HỎI TIẾP: "Bạn đã học gì để chuẩn bị?" Câu trả lời: Tên khóa, khoá giờ (Udemy? Online? Tự code?), học được cái gì. KHÔNG trả lời: "Mình chưa học gì, chỉ xin việc rồi tập." Đó là red flag.

Tránh những câu trả lời này:

❌ "Chán công việc cũ, muốn thay đổi." (Quá chung chung)
❌ "Testing kiếm tiền nhiều hơn." (Sai, fresher testing còn ít tiền hơn nhiều nghề khác)
❌ "Bạn bè mình vào testing nên mình vào theo." (Không có chủ kiến)
❌ "Mình chưa biết testing là gì, nhưng xin vào rồi học." (HR sẽ không lấy)

Những câu hỏi phỏng vấn tester fresher hay gặp

Khi phỏng vấn tester, HR hoặc kỹ sư test sẽ hỏi THỰC HÀNH - không hỏi lý thuyết nhiều. Mình liệt kê câu hỏi thường gặp và cách trả lời ngắn gọn.

344799 Các loại câu hỏi phỏng vấn tester fresher: từ cơ bản đến thực hành

1. "Test case là gì? Một test case tốt gồm những phần nào?"

Trả lời: "Test case là một kịch bản để kiểm tra 1 tính năng hoặc 1 flow cụ thể. Test case tốt gồm:

Test case ID: tên duy nhất (TC_001)
Mô tả: tính năng cần test
Precondition: điều kiện trước khi test (ví dụ: đã đăng nhập)
Test steps: các bước cụ thể (1, 2, 3...)
Expected result: kết quả mong đợi (phải cụ thể)
Actual result: kết quả thực tế (khi test)
Status: Pass / Fail

Ví dụ: Test case đăng nhập, bước 1 là 'nhập email', bước 2 là 'nhập password', bước 3 là 'click login'. Expected result là 'chuyển dashboard', không phải 'đăng nhập thành công' (quá chung chung)."

2. "Vậy test case nên viết bao nhiêu? Sao biết đủ hay chưa?"

Trả lời: "Không có con số cụ thể. Nhưng quy tắc là: cover các scenario chính.

Happy path: điều kiện tốt, mong đợi success (ví dụ: email đúng, password đúng → login thành công)
Unhappy path: điều kiện xấu, mong đợi fail (ví dụ: email sai, password sai, email không tồn tại)
Edge case: biên giới (ví dụ: password trống, email không có @, password quá dài)

Mình thường kiểm tra: cái tính năng này, user có thể sai sót chỗ nào? Hoặc, người code có thể quên validate chỗ nào? Thì test đó.

Đủ là khi mình tự tin: nếu code pass các test case này, app sẽ ổn. Nếu còn run test mà vẫn thấy bug, thì test case chưa đủ."

3. "Sự khác biệt giữa bug và defect là gì?"

Trả lời: "Ở mình, 2 cái này gần giống nhau. Bug hay defect đều là lỗi - khi actual result khác expected result.

Có thể phân chia theo severity (mức độ nghiêm trọng):

Critical: crash app, mất dữ liệu, security issue
High: tính năng chính không work
Medium: tính năng phụ không work, UI sai
Low: typo, icon sai, cosmetic

Khi report bug, mình ghi severity để dev biết ưu tiên fix cái nào trước."

4. "Difference giữa smoke test, sanity test, regression test là gì?"

Trả lời: "3 cái này khác nhau về TẠI SAO test, KHÔNG phải CỞI NÀO test.

Smoke test: test nhanh để kiểm tra app 'chạy được' hay không. Ví dụ: app mở được không, login được không, chính trang work không. Chạy sau deploy bản mới, nếu smoke fail thì không test tiếp.
Sanity test: khi dev fix 1 cái bug, test lại cái đó có fix đúng không. Giới hạn, nhanh.
Regression test: khi thay đổi feature A, test lại toàn bộ feature cũ (A, B, C, D) để đảm bảo fix feature A không làm hỏng cái khác.

Smoke là check nhanh 'app launch được không', sanity là 'bug fix đúng không', regression là 'fix này có break cái khác không'."

5. "Bạn viết test case thế nào? Có tool nào không?"

Trả lời: "Mình viết trên Excel hoặc Google Sheet (đơn giản, dễ share). Công ty lớn thường dùng TestLink hoặc Zephyr.

Quy trình mình:

Tường minh hiểu requirement
Chia feature thành function nhỏ
Mỗi function viết 3-5 test case (happy, unhappy, edge)
Ghi rõ precondition, steps, expected result
Review lại, xóa case trùng
Run test, ghi actual result

Ví dụ nếu feature là 'filter sản phẩm theo giá', mình sẽ test:

Filter từ 0 đến 100k → kết quả đúng?
Filter từ 100k đến 0 (reverse) → có bug không?
Filter với giá âm → validate được không?
Filter đơn giá rất lớn (9999999) → UI bị lỗi không?"

6. "Nếu phát hiện 1 bug, bạn sẽ report thế nào? Bug report có thành phần gì?"

Trả lời: "Bug report gồm những phần:

Bug ID: tên duy nhất
Title: mô tả ngắn bug (ví dụ: 'Nút login không responsive khi form trống')
Severity: Critical / High / Medium / Low
Steps to reproduce: các bước tái hiện bug (phải chi tiết, dev follow được)
Expected result: cái nên xảy ra
Actual result: cái xảy ra
Screenshot / video: bằng chứng
Environment: browser, OS, version app
Date: ngày phát hiện

Ví dụ: Khi mình click 'Forgot Password' mà không nhập email, nút 'Send' vẫn work. Expected: nút phải disabled hoặc báo lỗi. Mình chụp ảnh màn hình ghi chú, report đó.

Mẹo: Bug report phải chi tiết đến mức dev follow bước mà tái hiện được 100% bug. Nếu dev không reproduce được, họ sẽ dismiss report. Đó là lỗi tester."

7. "Bạn biết SQL không? Tại sao tester cần SQL?"

Trả lỏi: "Mình biết SQL cơ bản. Tester cần SQL để:

Verify dữ liệu trong database sau khi test (ví dụ: sau khi add product, check database có record mới không)
Delete test data (sau khi test, cần xóa data test ra khỏi database)
Query data để prepare test

Ví dụ câu lệnh cơ bản:

SELECT * FROM users WHERE email = '[email protected]'; → Check user này có trong database không
DELETE FROM users WHERE email = '[email protected]'; → Xóa user test
UPDATE orders SET status = 'completed' WHERE id = 123; → Update trạng thái order

Trên mình không cần viết query phức tạp, chỉ cần hiểu SELECT, INSERT, UPDATE, DELETE là đủ."

8. "Bạn đã từng test cái gì? Có project nào không?"

Trả lỏi: "Nếu chưa có project thực tế, nói về dự án tự học: 'Mình thực hành viết test case cho [app public như login Facebook, checkout Shopee, ...]. Mình viết Mẫu test case đăng nhập test case cho feature [cụ thể]. Từ đó mình học được cách design test case, cách report bug, cách think edge case.'

Nếu có project thực tế, mô tả:

App name
Khoảng thời gian test
Cách test (manual / automation)
Tìm được bao nhiêu bug, severity như thế nào
Khó khăn gặp phải và cách giải quyết

Ví dụ: 'Mình test project [tên], khoảng 3 tháng. Test manual vì team nhỏ. Mình viết 150+ test case, tìm được 25 bug (5 critical, 10 high, 10 medium/low). Khó khăn là requirement không rõ, mình phải hỏi lại product owner nhiều lần. Học được cách clarify requirement trước khi viết test case.'"

9. "Bạn sẽ làm gì nếu find bug nhưng dev nói là 'by design'?"

Trả lỏi: "Mình sẽ hỏi lại. Xong check requirement, spec, design doc xem có mention đến cái này không. Nếu requirement không clear, mình sẽ hỏi product owner hoặc designer: 'Behavior này có đúng không?' Nếu họ xác nhận là đúng, thì mình sẽ close bug và ghi note 'by design'.

Không nên để dạo: 'Trừu tượng dev nói là đúng thì phải là đúng.' Testing là role của QA, mình có quyền challenge. Nhưng phải polite, hỏi bằng evidence (requirement, screenshot, logic) chứ không phải 'mình thấy sai'."

10. "Bạn có câu hỏi gì cho chúng tôi không?"

Trả lời: Đây là cơ hội của bạn. Hỏi những câu có liên quan tới công việc, chứ không hỏi lương, chế độ (lúc phỏng vấn đầu tiên, tránh hỏi những cái này). Hỏi:

"Team testing bao nhiêu người?"
"Tech stack của company là gì? Automation test dùng gì? (Selenium, Postman, ...)"
"Ngoài test case, fresher tester sẽ học automation test không?"
"Career path của tester trong công ty như thế nào?"

Hỏi này cho thấy bạn quan tâm, không chỉ kiếm tiền.

Mẹo chung: Các câu hỏi trên đều CÓ ANSWER dúng/sai, nhưng LÀ TƯƠNG ĐỐI. Ví dụ: "test case bao nhiêu là đủ?" không có con số cụ thể. Quan trọng là bạn TỌ RÕ tư duy, logic của mình. Nếu HR hỏi "test case bao nhiêu?" và bạn trả lời "tùy theo requirement," họ sẽ hỏi tiếp "requirement của [feature cụ thể] thì bao nhiêu?" Bạn phải nói rõ: "Feature X thì mình test happy path + 5 edge case = 6 case. Feature Y thì 8 case." LÀM CÁCH ĐÓ TỎ RÕ BẠN BIẾT TƯ DUY.

Kiến thức chuẩn bị: Test case mẫu, SQL cơ bản, tools

Trước phỏng vấn, bạn cần luyện tập. Không cần học sâu, nhưng phải CÓ HANDS-ON EXPERIENCE. Mình khuyên:

1. Viết test case thực hành

Chọn 1 app bạn dùng hàng ngày (Facebook, Shopee, Gmail...) và viết test case cho 1 feature (login, search, filter, checkout). Viết 5-10 test case cover happy + unhappy + edge. Ghi rõ precondition, steps, expected result. Sau đó test thực tế, ghi actual result. Nếu tìm được bug, viết bug report. {{resource:1}} sẽ giúp bạn có framework.

344800 Quy trình luyện tập: từ chọn feature → viết test case → test thực tế → report bug

2. Học SQL cơ bản

Khóa học SQL từ Udemy hoặc freecodecamp là đủ. Bạn cần hiểu SELECT, INSERT, UPDATE, DELETE, WHERE clause. VÍ DỤ:

SELECT * FROM products WHERE price > 100; (lấy sản phẩm giá > 100)
INSERT INTO users VALUES (...); (thêm user mới)
UPDATE orders SET status = 'shipped' WHERE id = 123; (update trạng thái order)
DELETE FROM test_data WHERE created_date < '2024-01-01'; (xóa data cũ)

Sau khi học, thực hành query trên môi trường test (database test do công ty cung cấp khi bạn phỏng vấn, hoặc dùng demo database online).

3. Làm quen với tools

Bạn không cần biết tất cả, nhưng ít nhất cần biết CÁCH HỌC từng tool:

Jira: Tool quản lý test case, bug report. Mỗi company khác setup, nhưng logic giống nhau. Tạo ticket, ghi detail, assign người.
Postman: Tool test API. Nếu bạn sẽ test API, learn Postman (ngay cả tutorial cơ bản).
Excel / Google Sheet: Tool viết test case cơ bản. Bạn chắc chắn dùng cái này.

4. Trước phỏng vấn 1 tuần

Mình khuyên:

Review lại 10 câu hỏi trên + mẫu trả lời
Thực hành viết 1 test case set dầy đủ (10+ case)
Chuẩn bị 1-2 dự án tự học để nói tại phỏng vấn
Ghi nhớ lý do chuyển ngành (phải phát biểu được 1 phút, thuyết phục)
Review CV 1 lần cuối, chắc chắn không typo

5. Mindset lúc phỏng vấn

Bạn là fresher, HR biết bạn chưa biết nhiều. Mục tiêu của họ không phải test bạn có biết mọi thứ, mà test BẠN CÓ THỂ HỌC, BẠN CÓ TƯ DUY TESTING không.

Nếu HR hỏi cái bạn không biết, hãy nói: "Mình chưa học phần này, nhưng mình hiểu logic là [...]. Mình sẽ learn nhanh nếu vào công ty." Đừng nói: "Mình không biết." Đó là 2 cách trả lời khác nhau. Cách đầu tỏ ra bạn CÓ THỂ HỌC, cách sau tỏ ra bạn bỏ cuộc.

Cuối cùng: Test hay không test, Success hay fail, đều là feedback. Fresher tester thường mất 2-3 lần phỏng vấn mới pass. Không sao, cái quan trọng là PERSIST. Mình từng fail 2 lần trước khi vào được. Lần 3, mình tự tin hơn, trả lời rõ ràng hơn, và vào được. Bạn cũng vậy.

Checklist chuẩn bị phỏng vấn tester fresher

1-2 tuần trước:

[ ] Chuẩn bị CV (theo mẫu Tải mẫu CV tester)
[ ] Viết lý do chuyển ngành (mẫu trên)
[ ] Học SQL cơ bản (SELECT, UPDATE, DELETE)
[ ] Thực hành viết 1 bộ test case đầy đủ

1 tuần trước:

[ ] Review 10 câu hỏi phỏng vấn + trả lời
[ ] Tập nói lý do chuyển ngành (1 phút)
[ ] Chuẩn bị 1-2 dự án tự học để kể
[ ] Review CV, chắc chắn không typo

Ngày phỏng vấn:

[ ] Mặc trang phục lịch sự (không cần quá formal, nhưng sạch sẽ)
[ ] Tới sớm 5-10 phút
[ ] Nên đạt mắt, nói rõ ràng
[ ] Ghi chú nếu HR nói quá nhanh (polite để hỏi lại)
[ ] Cuối cùng, hỏi HR 2-3 câu về công ty / công việc

Nếu fail:

[ ] Hỏi feedback ("Mình fail chỗ nào? Mình có thể improve như thế nào?")
[ ] Ghi nhớ feedback
[ ] Luyện tập thêm 1-2 tuần
[ ] Apply lại công ty khác hoặc apply lại sau 1-2 tháng

Lời cuối: Chuyển ngành vào tester không khó bằng bạn tưởng. Nó chỉ cần bạn CHUẨN BỊ KỸ + TƯ DUY ĐÚNG. CV tốt + lý do thuyết phục + kiến thức cơ bản = pass phỏng vấn. Hơn nữa, bạn từ trái ngành, HỌC NGÀNH TESTING MỚI - điều này làm cho bạn FRESH, có TƯ DUY MỚI. Công ty cần fresher như bạn, người đủ tỉ mỉ, đủ logic, đủ quyết tâm.

Mình tin bạn sẽ vào. Comment bên dưới nếu có câu hỏi gì nhé!