# Manual Vs Automation Testing: Nên Chọn Gì?

> Câu hỏi manual vs automation testing — nên chọn gì — là thứ tôi được học viên hỏi gần như mỗi khóa. 🙂 Nhiều bạn nghĩ đây là cuộc chọn phe: hoặc theo manual, hoặc nhảy hẳn sang automation. Nhưng sau 18…

- **URL canonical**: https://itlearn.edu.vn/blog/manual-vs-automation-testing
- **Published**: 2026-07-17T11:00:00+07:00
- **Modified**: 2026-07-17T13:25:38+07:00
- **Author**: Anh Tuấn
- **Category**: Automation test (https://itlearn.edu.vn/blog/cat/automation-test)
- **Reading time**: 13 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

Câu hỏi **manual vs automation testing** — nên chọn gì — là thứ tôi được học viên hỏi gần như mỗi khóa. 🙂 Nhiều bạn nghĩ đây là cuộc chọn phe: hoặc theo manual, hoặc nhảy hẳn sang automation. Nhưng sau 18 năm làm QC, tôi khẳng định chúng không loại trừ nhau. Bài này tôi sẽ so sánh sòng phẳng bằng bảng, chỉ rõ mỗi bên mạnh ở đâu, khi nào nên tự động hóa và cái gì thì đừng, để bạn tự chọn đúng cho hoàn cảnh của mình.

![Manual vs automation testing - bảng so sánh điểm mạnh yếu và khi nào nên tự động hóa](/uploads/2026/07/manual-vs-automation-testing.jpg)

## Manual vs automation — bảng so sánh nhanh

**Manual vs automation testing khác nhau ở cách thực thi: manual testing là con người trực tiếp thao tác và quan sát kết quả, còn automation testing dùng script/công cụ chạy lại các ca kiểm thử tự động.** Manual mạnh ở tư duy, linh hoạt và cảm nhận trải nghiệm; automation mạnh ở tốc độ, lặp lại và độ phủ khi chạy hồi quy nhiều lần. Không cái nào thay thế hoàn toàn cái kia.

Bảng dưới tóm tắt khác biệt cốt lõi để bạn nắm nhanh trước khi đi sâu:

Tiêu chí

Manual testing

Automation testing

Cách thực thi

Người trực tiếp thao tác, quan sát

Script/công cụ chạy tự động

Chi phí ban đầu

Thấp — bắt tay test ngay

Cao — phải viết & dựng script trước

Chi phí khi lặp lại

Cao (tốn người mỗi lần)

Rất thấp (chạy lại gần như miễn phí)

Tốc độ chạy

Chậm

Nhanh, chạy song song được

Phù hợp nhất với

Exploratory, UX, test chạy 1–2 lần

Regression, smoke, test lặp ổn định

Phát hiện lỗi mới, bất ngờ

Rất tốt — con người suy luận

Kém — chỉ bắt cái đã lập trình để kiểm

Cảm nhận trải nghiệm

Có (đẹp/xấu, khó dùng)

Không

Yêu cầu kỹ năng

Tư duy kiểm thử, nghiệp vụ

Thêm lập trình, biết công cụ

Như bạn thấy, đây không phải cuộc đua "ai thắng ai". Mỗi hướng gánh một loại việc khác nhau. Phần dưới tôi làm rõ điểm mạnh từng bên rồi mới bàn cách phối hợp.

## Manual testing mạnh ở đâu

**Manual testing mạnh nhất ở những việc cần bộ não con người: suy luận, phán đoán ngữ cảnh và cảm nhận trải nghiệm.** Đây là những thứ không thể "đóng gói" thành script. Theo tinh thần ISTQB, kiểm thử là một hoạt động trí tuệ, không chỉ là thao tác cơ học — và đó chính là địa hạt của manual.

Lấy ví dụ quen thuộc trong loạt bài của tôi — hệ thống đặt phòng họp nội bộ. Khi tính năng "đặt phòng định kỳ hằng tuần" vừa ra, một tester manual giỏi sẽ mò mẫm đủ kiểu: đặt trùng ngày lễ, đổi múi giờ, hủy một buổi trong chuỗi rồi xem chuỗi còn lại thế nào. Kiểu thử này — **exploratory testing** — dựa vào trực giác và kinh nghiệm, sinh ca kiểm thử ngay trong lúc test. Automation không làm được vì nó chỉ chạy đúng cái đã được lập trình sẵn.

Manual còn vượt trội ở kiểm thử trải nghiệm người dùng (UX): nút bấm có dễ thấy không, thông báo lỗi có dễ hiểu không, luồng đặt phòng có "mượt" không. Đó là những đánh giá mang tính cảm nhận mà chỉ con người mới đưa ra được. Ngoài ra, với tính năng chỉ test một hai lần rồi thôi, viết script tự động hóa thường lỗ vốn — làm tay nhanh và rẻ hơn nhiều. Nếu bạn mới vào nghề, [Manual Testing là gì](/blog/manual-testing-la-gi-lo-trinh) là điểm khởi đầu để xây nền tư duy này.

## Automation mạnh ở đâu

**Automation testing mạnh nhất ở việc lặp lại: chạy cùng một bộ ca kiểm thử hàng trăm lần, nhanh, chính xác và không biết mệt.** Sức mạnh của nó không nằm ở "tìm lỗi mới" mà ở "canh gác chống lỗi cũ quay lại" — tức kiểm thử hồi quy (regression). Mỗi lần dev sửa code, bộ automation chạy lại toàn bộ để đảm bảo cái đang chạy không bị vỡ.

Với hệ thống đặt phòng họp, hãy tưởng tượng mỗi lần release phải kiểm lại 200 ca cơ bản: đăng nhập, đặt phòng, hủy phòng, phân quyền... Làm tay thì ngốn cả ngày người và dễ sót. Automation chạy hết trong vài phút, chạy song song nhiều trình duyệt, và nhét thẳng vào pipeline CI để test tự động sau mỗi commit. Một script Playwright kiểm luồng đặt phòng trông gọn thế này:

`javascript
test('đặt phòng họp thành công', async ({ page }) => {
 await page.goto('/booking');
 await page.getByLabel('Phòng').selectOption('Phòng A');
 await page.getByRole('button', { name: 'Đặt' }).click();
 await expect(page.getByText('Đặt phòng thành công')).toBeVisible();
});`

Chạy một lần thì tốn công viết, nhưng chạy lại lần thứ 50 thì gần như miễn phí — đó là lúc automation "hoàn vốn". Các công cụ phổ biến gồm Selenium, Cypress, Playwright cho UI và Postman/Newman cho API. Muốn hiểu bức tranh tổng thể, đọc [Automation testing là gì](/blog/automation-testing-la-gi); còn nếu tính chuyển hướng sự nghiệp, tôi có hẳn một bài về lộ trình [từ Manual sang Automation](/blog/manual-sang-automation).

## Khi nào nên tự động hóa (tiêu chí)

Không phải test nào cũng đáng tự động hóa. Automation là một khoản đầu tư — tốn công viết và bảo trì script — nên chỉ "lãi" khi ca kiểm thử được chạy đi chạy lại nhiều lần. Dưới đây là tiêu chí thực dụng tôi hay dùng để quyết định.

**Nên tự động hóa khi ca kiểm thử:**

- **Chạy lặp nhiều lần** — regression, smoke test sau mỗi build, mỗi release.

- **Ổn định, ít đổi** — luồng nghiệp vụ cốt lõi đã chốt, giao diện không thay xoành xoạch.

- **Tốn công nếu làm tay** — nhập nhiều dữ liệu, kiểm nhiều tổ hợp (data-driven).

- **Cần chạy trong CI** — muốn phản hồi tự động, nhanh sau mỗi commit.

- **Đo lường được rõ ràng** — kết quả đúng/sai xác định, không cần phán đoán chủ quan.

**KHÔNG nên (hoặc chưa nên) tự động hóa:**

- **Exploratory testing** — cần tư duy ứng biến, không có kịch bản cố định để script hóa.

- **Kiểm thử UX/thẩm mỹ** — "đẹp", "dễ dùng" là cảm nhận, máy không chấm được.

- **Test chỉ chạy một lần** — tính năng dùng một lần rồi bỏ; viết script không kịp hoàn vốn.

- **Màn hình còn thay đổi liên tục** — giao diện chưa ổn định thì script vỡ suốt, bảo trì mệt hơn làm tay.

- **Ca cần mắt người phán đoán** — CAPTCHA, nội dung động khó xác định trước kết quả đúng.

Quy tắc ngón tay cái: **tự động hóa cái nhàm chán và lặp lại, để dành đầu óc con người cho cái mới và cần suy nghĩ.** Muốn xem toàn cảnh các nhóm kiểm thử để biết cái nào hợp automation, bạn đọc thêm [các loại kiểm thử](/blog/cac-loai-kiem-thu).

## Tester nên học gì trước

Nếu bạn là người mới và phân vân **manual hay automation**, lời khuyên thẳng của tôi là **học manual trước, chắc nền rồi mới lên automation**. Lý do rất đơn giản: automation chỉ là công cụ để chạy lại các ca kiểm thử; còn *thiết kế* ca kiểm thử nào cho đáng — phủ case hợp lệ, không hợp lệ, biên — mới là gốc rễ, và tư duy đó học qua manual tự nhiên nhất.

Một sự thật hay bị bỏ qua: người viết automation giỏi trước hết phải là tester giỏi. Nếu bạn không biết ca kiểm thử nào quan trọng, script bạn viết ra cũng chỉ tự động hóa những thứ vô nghĩa — chạy nhanh mà chẳng bắt được lỗi. Vì thế lộ trình tôi hay gợi ý là: nắm nền tảng kiểm thử và cách viết test case → làm manual thật vững trên dự án → rồi học một ngôn ngữ (thường JavaScript hoặc Python) và một công cụ automation.

Về công cụ, tôi khuyên người mới bắt đầu với Playwright hoặc Cypress vì cú pháp hiện đại, dễ đọc và tài liệu tốt. Đừng cố ôm cả rừng công cụ; chọn một cái, làm chủ nó trên dự án thật rồi mở rộng sau. Cơ hội và mức lương phụ thuộc kỹ năng thực tế của mỗi người, nhưng theo quan sát của tôi, tester biết cả manual lẫn automation thường có nhiều lựa chọn dự án hơn hẳn. Nếu muốn học automation bài bản với Playwright và thực hành trên dự án thật, bạn có thể tham khảo [khóa Automation Testing](/playwright.html) của IT LEARN.

## Câu hỏi thường gặp

### Nên học manual hay automation trước?

Nên học manual trước. Automation chỉ là công cụ chạy lại ca kiểm thử, còn tư duy thiết kế test case — phủ case hợp lệ, không hợp lệ, biên — là gốc rễ và học qua manual tự nhiên nhất. Chắc nền manual rồi mới học ngôn ngữ và công cụ automation thì bạn tiến nhanh và vững hơn nhiều.

### Automation có thay thế manual không?

Không. Automation chỉ tự động hóa việc thực thi các ca lặp lại, không thay được tư duy con người. Exploratory testing, đánh giá UX và những ca cần phán đoán ngữ cảnh vẫn cần manual. Automation gánh regression để tester rảnh tay cho việc cần suy nghĩ — hai hướng bổ trợ nhau chứ không loại trừ nhau.

### Khi nào nên tự động hóa test?

Nên tự động hóa khi ca kiểm thử chạy lặp nhiều lần, ổn định ít đổi, tốn công nếu làm tay, và có kết quả đúng/sai rõ ràng — điển hình là regression và smoke test trong CI. Automation là khoản đầu tư, chỉ "hoàn vốn" khi ca được chạy đi chạy lại đủ nhiều lần.

### Test nào không nên automation?

Không nên tự động hóa exploratory testing, kiểm thử UX/thẩm mỹ, test chỉ chạy một lần, và màn hình còn thay đổi liên tục. Đó là những việc cần tư duy ứng biến hoặc cảm nhận của con người, hoặc chưa đủ ổn định để script hóa mà không tốn công bảo trì hơn cả làm tay.

### Manual tester có lỗi thời không?

Không. Manual tester vẫn cần cho exploratory, UX và mọi ca cần phán đoán mà máy không làm được. Điều thay đổi là kỳ vọng thị trường: tester nên biết thêm automation để mở rộng cơ hội. Kết hợp tư duy manual vững với kỹ năng automation là hướng đi bền nhất hiện nay. Tóm lại, manual và automation testing không phải hai lựa chọn loại trừ — chúng là hai kỹ năng bổ trợ trong một tester giỏi. Hãy chắc nền tảng bằng [Manual Testing là gì](/blog/manual-testing-la-gi-lo-trinh), rồi khi sẵn sàng lên automation, tham khảo [khóa Automation Testing](/playwright.html) của IT LEARN.