QA vs QC vs Tester: Phân Biệt Rõ Để Tránh Nhầm Lẫn Khi Chuyển Nghề
7 tháng trước · 17 phút đọc
Ba cái tên, ba công việc - đừng để nhầm lẫn trong phỏng vấn
Bạn đang chuẩn bị chuyển sang lĩnh vực IT và tìm kiếm việc làm liên quan đến "kiểm thử phần mềm". Mở LinkedIn lên, thấy đủ thứ: "QA Engineer", "QC Tester", "Software Tester", "Quality Assurance Analyst"... Tất cả nghe có vẻ giống nhau, nhưng thực ra không phải vậy.
Mình nhớ hồi mới vào nghề, mình cũng nghĩ ba cái này là một. Kết quả là phỏng vấn vào vị trí QA mà cứ nói chuyện test case, bug report - nhà tuyển dụng nhìn mình với ánh mắt nghi ngờ. Sau buổi đó mình mới hiểu: họ cần người thiết kế quy trình, không phải người ngồi click test.
Bài này mình sẽ giải thích rõ từng vị trí, vai trò thực tế trong dự án, và quan trọng hơn - giúp bạn tự đánh giá mình phù hợp với cái nào trước khi đi phỏng vấn.
Ba vị trí khác nhau, nhưng cùng chung một mục tiêu: sản phẩm không có lỗi
Một điều mình muốn nói trước: không có vị trí nào "thấp hơn" hay "cao hơn" ở đây. Mỗi vị trí có trách nhiệm riêng, và cả ba đều cần thiết trong một dự án phần mềm chạy tốt.
QA (Quality Assurance) là gì?
QA - đảm bảo chất lượng (Quality Assurance) - là người xây dựng và duy trì quy trình để đảm bảo sản phẩm ra đúng chất lượng. Nhấn mạnh từ "quy trình" nhé.
Nếu bạn hỏi: "QA làm gì mỗi ngày?", câu trả lời không phải "ngồi click test tính năng". QA làm những việc như:
- Xây dựng quy trình kiểm thử cho cả team (test process)
- Định nghĩa tiêu chí chất lượng: khi nào sản phẩm được gọi là "đạt"
- Review tài liệu yêu cầu (requirement) sớm - trước khi code
- Phân tích root cause khi bug xảy ra, đề xuất cải tiến quy trình
- Theo dõi metrics chất lượng: bug rate, test coverage, thời gian fix bug
QA làm việc với quy trình và tài liệu nhiều hơn là click test
Một ví dụ thực tế: Công ty fintech ở Hà Nội có đội 5 dev, 2 tester, 1 QA. QA không tự tay test từng tính năng - họ xây quy trình: tester phải viết test case theo template nào, bug report cần có thông tin gì, release checklist gồm những bước nào. Khi bug nổ production, QA phân tích: tại sao quy trình không bắt được bug này? Cần thêm bước gì?
Nói ngắn gọn: QA nhìn vào hệ thống, không nhìn vào từng tính năng.
Vị trí này thường yêu cầu kinh nghiệm nhất định - ít nhất 2-3 năm làm testing trước. Nếu bạn đang chuyển nghề và mới bắt đầu, QA không phải điểm xuất phát phù hợp. Nhưng biết QA làm gì giúp bạn hiểu ngành rộng hơn.
QC (Quality Control) là gì?
QC - kiểm soát chất lượng (Quality Control) - là người kiểm tra sản phẩm/tính năng đã được xây dựng xong, đối chiếu với yêu cầu, và xác nhận đạt hay không đạt.
QC gần với "kiểm tra" hơn là "thiết kế quy trình". Họ hoạt động ở giai đoạn cuối của từng chu kỳ phát triển. Cụ thể:
- Nhận bàn giao tính năng từ dev
- Kiểm tra tính năng có đúng yêu cầu không
- Phát hiện lỗi, ghi nhận, báo cáo
- Xác nhận lỗi đã fix trước khi release
- Kiểm tra hồi quy (regression testing) - tức test lại tính năng cũ đảm bảo không bị ảnh hưởng sau khi fix
QC kiểm tra sản phẩm đã xong - như kiểm định hàng hóa trước khi xuất xưởng
Ví dụ: Công ty làm app đặt đồ ăn. Dev vừa hoàn thành tính năng "lọc theo khoảng cách". QC nhận task, mở app, test: lọc 1km có đúng không, lọc 5km có đúng không, điều gì xảy ra nếu để trống, tắt GPS thì sao. Tìm thấy bug, tạo bug report chi tiết. Dev fix xong, QC verify lại. Ổn thì sign off - tính năng được release.
Sự khác biệt với QA: QA hỏi "quy trình của chúng ta có đúng không?", QC hỏi "sản phẩm này có đúng không?"
Nhiều công ty Việt Nam - đặc biệt startup và công ty vừa - gộp QA và QC vào một vị trí, gọi là "QA/QC" hoặc đơn giản là "QA". Bạn cần đọc kỹ job description để hiểu họ thực sự cần gì.
Tester là gì - và tại sao đây là điểm xuất phát tốt nhất?
"Tester" là từ mô tả người thực hiện việc kiểm thử - có thể là manual tester (kiểm thử thủ công) hoặc automation tester (kiểm thử tự động).
Trên thực tế, "Tester" là chức danh phổ biến nhất ở Việt Nam cho người mới vào nghề. Khi công ty đăng tuyển "Software Tester" hay "Manual Tester", họ cần người:
- Viết test case dựa trên tài liệu yêu cầu
- Thực hiện test case: bước tay test từng tình huống
- Phát hiện bug và viết bug report chi tiết
- Retest sau khi dev fix
- Tham gia các loại kiểm thử: smoke testing, regression testing, UAT
Tester làm việc sát với dev và sản phẩm nhất trong vòng lặp phát triển
Vì sao đây là điểm xuất phát tốt cho người chuyển nghề? Vì bạn học được cái gốc rễ của ngành. Viết test case giỏi, hiểu bug report chuẩn, quen với vòng lặp dev-test-fix - đây là nền tảng để sau này lên QC rồi QA.
Thêm nữa, không cần biết code để bắt đầu làm Manual Tester. Bạn cần logic tốt, tư duy tỉ mỉ, và khả năng đặt câu hỏi "điều gì xảy ra nếu...". Đó là thứ nhiều người trái ngành - kế toán, y tế, giáo viên - hoàn toàn có.
Mình từng đào tạo một bạn từng làm nhân viên ngân hàng 6 năm. Tư duy quy trình và chú ý đến từng con số của bạn ấy vượt xa nhiều bạn IT chính quy. Sau 4 tháng, bạn ấy có việc làm tester đầu tiên.
Không muộn. Không cần background IT.
So sánh nhanh QA - QC - Tester
Đây là bảng mình hay dùng khi giải thích cho các bạn mới:
| Tiêu chí | QA | QC | Tester |
|---|---|---|---|
| Tập trung vào | Quy trình | Sản phẩm | Tính năng cụ thể |
| Câu hỏi chính | "Quy trình đúng chưa?" | "Sản phẩm đúng chưa?" | "Tính năng này chạy đúng chưa?" |
| Giai đoạn hoạt động | Suốt dự án | Gần cuối sprint | Trong sprint |
| Output | Quy trình, policy, metrics | Report chất lượng tổng thể | Test case, bug report |
| Yêu cầu kinh nghiệm | 3+ năm | 1-3 năm | 0-1 năm |
| Phù hợp người mới | Không | Một phần | Có |
Ba vị trí phối hợp nhau - không phải thay thế nhau
Một điều quan trọng: ở nhiều công ty Việt Nam, ranh giới này không rõ ràng. Startup 20 người thường chỉ có 1-2 người làm testing, và họ phải làm cả ba vai trò. Công ty outsource lớn thì phân công rõ hơn.
Khi đọc job description, đừng chỉ nhìn tiêu đề. Đọc kỹ phần "Mô tả công việc" để hiểu thực sự họ cần gì. Tiêu đề "QA Engineer" nhưng 90% mô tả là viết test case và báo cáo bug? Thực chất họ cần Tester.
Vai trò thực tế trong dự án - ví dụ từ công ty Việt Nam
Lý thuyết một chút là đủ. Mình kể bạn nghe ba tình huống thực tế.
Tình huống 1: Startup thương mại điện tử, 15 người Công ty có 1 người làm "QA" nhưng thực tế làm tất: viết test case, test tay, báo cáo bug, đôi khi ngồi xây dựng checklist release. Không có phân chia rõ QA/QC/Tester. Đây là thực tế ở nhiều startup Việt Nam.
Tình huống 2: Công ty outsource, 100+ người Đội testing có cấu trúc rõ: 1 QA Lead (xây quy trình, mentor team), 3 QC (phụ trách từng module, sign off release), 8 Tester (viết và chạy test case hàng ngày). Tuyển dụng phân chia rạch ròi, phỏng vấn hỏi đúng kỹ năng từng cấp.
Tình huống 3: Công ty fintech, 50 người Gọi tất cả là "QA" nhưng phân cấp theo level: QA Junior (thực chất làm Tester), QA Mid (làm QC + một phần Tester), QA Senior/Lead (làm QA thực sự). Chức danh giống nhau, công việc khác nhau.
Một dự án điển hình: Tester nhiều nhất, QA ít nhất - nhưng cả ba đều cần
Bài học từ ba tình huống này: khi đi phỏng vấn, hỏi thẳng: "Trong công ty mình, đội testing phân chia vai trò như thế nào? Vị trí này cụ thể sẽ làm những gì?" Câu hỏi này vừa giúp bạn hiểu rõ công việc, vừa cho nhà tuyển dụng thấy bạn nghiêm túc và có tư duy.
Đừng ngại hỏi. Hỏi đúng trong phỏng vấn là dấu hiệu tốt.
Checklist tự đánh giá: Bạn phù hợp với vị trí nào?
Mình tổng hợp checklist này sau nhiều buổi tư vấn cho các bạn chuyển nghề. Đọc và tự đánh dấu vào cái mô tả bạn nhất.
Bạn phù hợp làm Tester nếu:
- Thích thực hành hơn lý thuyết - muốn dùng app, khám phá tính năng
- Tỉ mỉ với từng chi tiết nhỏ (hay tự hỏi "cái này có hoạt động đúng không?")
- Thích tìm lỗi - cảm thấy thỏa mãn khi phát hiện ra điều gì đó sai
- Kiên nhẫn làm lại quy trình nhiều lần
- Chưa có kinh nghiệm IT - muốn bắt đầu từ đầu
Bạn phù hợp làm QC nếu:
- Có 1-2 năm kinh nghiệm testing rồi
- Thích nhìn tổng thể một module/tính năng, không chỉ từng bước nhỏ
- Quen với việc đánh giá và ra quyết định ("pass" hay "fail" cho cả phiên bản)
- Có kinh nghiệm quản lý tài liệu, báo cáo
- Background kế toán, quản lý chất lượng, hay ngành có quy trình kiểm soát
Bạn phù hợp làm QA nếu:
- Đã có 3+ năm trong testing
- Thích xây dựng hệ thống và quy trình hơn là thực thi
- Hay nhận xét "quy trình này không hợp lý" và muốn cải thiện
- Có khả năng nhìn xa: dự đoán rủi ro trước khi xảy ra
- Từng quản lý người hoặc project nhỏ
Chọn đúng vị trí từ đầu giúp bạn phát triển nhanh hơn rất nhiều
Tải checklist đầy đủ để điền và lưu lại: Tải checklist tự đánh giá QA/QC/Tester
Một lời khuyên thực tế: nếu bạn đang ở bước đầu chuyển nghề, đừng đặt mục tiêu QA ngay. Bắt đầu từ Tester, học đúng nền tảng, tích lũy kinh nghiệm. Con đường tự nhiên là Tester → QC → QA, và mỗi bước bạn sẽ hiểu sâu hơn tại sao bước tiếp theo lại cần thiết.
Những câu hỏi phỏng vấn thường gặp - và cách trả lời đúng
Biết lý thuyết xong, phần này mình muốn bạn chuẩn bị thực tế hơn. Đây là những câu phỏng vấn mình hay nghe phản hồi từ các bạn sau buổi phỏng vấn.
Câu 1: "Bạn hiểu sự khác nhau giữa QA và QC là gì?"
Câu này kiểm tra bạn có hiểu ngành không. Trả lời sai phổ biến nhất: nói rằng QA và QC là một. Trả lời tốt: "QA xây dựng quy trình để ngăn lỗi xảy ra, QC kiểm tra sản phẩm để phát hiện lỗi đã xảy ra. Một cái phòng ngừa, một cái kiểm soát."
Câu 2: "Trong team trước bạn đóng vai trò gì?"
Nếu bạn chưa có kinh nghiệm IT: thành thật. "Mình chưa làm trong môi trường IT, nhưng qua quá trình tự học mình đã thực hành viết test case cho app X và báo cáo bug theo format Y." Cụ thể luôn tốt hơn mơ hồ.
Câu 3: "Bạn thích làm Manual hay Automation Testing?"
Nếu bạn mới: "Mình muốn xây nền tảng vững từ manual testing trước - hiểu rõ ứng dụng, viết test case tốt. Automation là mục tiêu dài hạn mình đang học song song."
Trả lời phỏng vấn trúng vấn đề quan trọng hơn dài dòng
Câu 4: "Bạn có kinh nghiệm với Jira/TestRail không?"
Nếu chưa dùng thật: "Mình chưa dùng trong môi trường thực, nhưng mình đã tự học qua tài liệu và thực hành trên bản trial. Mình tin có thể làm quen nhanh." Đừng nói "biết" khi chưa biết - nhà tuyển dụng sẽ hỏi sâu hơn.
Nguyên tắc khi phỏng vấn: thành thật về những gì chưa biết, tự tin về những gì đã học. Đây không phải thi cử - người phỏng vấn muốn biết bạn có tư duy phù hợp và khả năng học hỏi không, không phải bạn nhớ hết định nghĩa không.
Bắt đầu từ đâu nếu bạn muốn làm Tester?
Nếu đọc đến đây bạn đã xác định muốn bắt đầu từ vị trí Tester - đây là các bước cụ thể.
Bước đầu tiên: hiểu cơ bản về vòng đời phát triển phần mềm (Software Development Life Cycle - SDLC). Bạn không cần biết code, nhưng cần biết phần mềm được tạo ra như thế nào: từ yêu cầu → thiết kế → code → test → release. Tester tham gia ở giai đoạn test, nhưng hiểu toàn bộ vòng lặp giúp bạn đặt câu hỏi đúng hơn.
Bước hai: học viết test case. Đây là kỹ năng cốt lõi. Test case là kịch bản bạn tự đặt ra: "Nếu tôi làm X, hệ thống phải phản hồi Y". Bắt đầu bằng ứng dụng bạn dùng hàng ngày - đặt đồ ăn, chuyển tiền, đăng nhập mạng xã hội.
Bước ba: học viết bug report. Bug report tốt cần: tiêu đề mô tả lỗi rõ ràng, các bước tái hiện lỗi (reproduce steps), kết quả thực tế, kết quả mong đợi, môi trường test (thiết bị, OS, version). Bug report tệ là nguyên nhân số một khiến dev không fix được đúng lỗi.
Ba kỹ năng cốt lõi mọi Tester cần nắm vững từ ngày đầu
Bước bốn: làm quen với ít nhất một tool quản lý bug. Jira là phổ biến nhất ở Việt Nam - bạn có thể thực hành trên bản miễn phí. Biết dùng Jira cơ bản là lợi thế rõ ràng khi phỏng vấn.
Tài nguyên bổ sung: Tài liệu ISTQB cơ bản cho Tester mới
Mình biết bắt đầu từ con số 0 nghe có vẻ nhiều. Nhưng chia nhỏ ra: mỗi tuần học một kỹ năng, thực hành trên app thật, ghi lại những gì bạn làm. Sau 2-3 tháng, bạn có đủ để bắt đầu apply. Không cần hoàn hảo - cần đủ tự tin và đủ nền tảng để học tiếp khi đi làm.
Testing không khó. Khó là kiên trì và tỉ mỉ trong từng bước nhỏ. Nếu bạn đọc đến đây, mình nghĩ bạn đã có phần kiên trì đó rồi. Comment bên dưới nếu bạn có câu hỏi - mình trả lời từng bạn nhé.