Manual Testing là gì? Vì sao người mới nên học manual trước automation

một tháng trước · 12 phút đọc
Manual testing là gì?
Mình nhớ ngày đầu bước vào nghề, cứ nghĩ testing là ngồi bấm máy tính kiểu... ngẫu nhiên. Sau mấy tuần làm thật mới hiểu: testing có quy trình, có logic, và manual testing là nền tảng của tất cả.
Manual testing là quá trình kiểm thử phần mềm bằng tay - tức người tester trực tiếp thực hiện từng bước để kiểm tra xem phần mềm hoạt động đúng như yêu cầu không, mà không dùng script hay tool tự động hóa.
Hình dung thế này: bạn đang mua hàng trên Shopee, bạn bấm "Thêm vào giỏ hàng", "Thanh toán", rồi kiểm tra xem tiền có bị trừ đúng không, đơn hàng có tạo ra đúng không. Đó chính xác là những gì manual tester làm - nhưng có kịch bản (test case) rõ ràng, và ghi lại kết quả từng bước.
Manual tester thực hiện từng bước kiểm tra, ghi lại kết quả - không bỏ qua bước nào
Quy trình manual testing thường đi theo vòng lặp:
- Đọc yêu cầu (requirement) - hiểu tính năng cần test là gì
- Viết test case - liệt kê từng kịch bản cần kiểm tra
- Thực thi test case - bấm tay theo từng bước
- Ghi kết quả - pass hay fail, nếu fail thì mô tả lỗi
- Báo cáo bug - nếu phát hiện lỗi, viết bug report đầy đủ để dev fix
Không có bước nào thừa. Bỏ bước 1 thì bạn không hiểu mình đang test gì. Bỏ bước 2 thì test xong không ai biết bạn đã check những gì. Bỏ bước 5 thì dev không biết cách tái hiện lỗi để fix.
Các loại manual testing phổ biến
Không phải cứ test là test giống nhau. Mỗi loại có mục đích riêng, và hiểu đúng từng loại giúp bạn biết mình đang làm gì - không phải bấm máy tính cho qua ngày.
Functional testing (kiểm thử chức năng): kiểm tra xem từng chức năng có hoạt động đúng không. Ví dụ: nút "Đăng nhập" có cho vào được tài khoản không, form đặt hàng có lưu thông tin đúng không. Đây là loại test phổ biến nhất, tester mới nào cũng làm hàng ngày.
Smoke testing (kiểm tra khói): nghe tên lạ nhưng thực ra đơn giản - là bật điện thoại lên xem có sáng không. Mỗi lần dev đưa bản build mới, tester chạy nhanh 10-15 test case quan trọng nhất để xác nhận app có khởi động được không, tính năng chính có chạy không. Nếu smoke testing fail thì trả lại dev, không test tiếp vì nền tảng đã hỏng.
Sanity testing (kiểm tra tỉnh táo): tập trung vào đúng vùng vừa được fix hoặc thay đổi. Ví dụ: dev fix bug thanh toán, sanity testing chỉ kiểm tra khu vực thanh toán, không test toàn bộ app.
Smoke testing kiểm tra nhanh toàn diện, sanity testing đi sâu vùng vừa thay đổi - hai loại khác nhau
Regression testing hay kiểm thử hồi quy: sau mỗi lần sửa bug hoặc thêm tính năng, tester phải test lại các tính năng cũ đảm bảo chúng chưa bị ảnh hưởng. Mình từng bỏ qua bước này vì nghĩ "dev chỉ sửa mỗi phần thanh toán, chắc phần giỏ hàng không sao" - kết quả là giỏ hàng bị lỗi mà không ai biết cho đến khi user báo. Bài học đắt giá.
Exploratory testing (kiểm thử khám phá): không có test case viết sẵn, tester tự do khám phá app để tìm bug bằng trực giác và kinh nghiệm. Kiểu "đặt mình vào vị trí user" và nghĩ xem họ sẽ dùng thế nào, hay thử những thứ "không ai nghĩ sẽ làm" như nhập ký tự đặc biệt, để form trống, bấm nhanh nhiều lần.
Bạn không cần nhớ hết tất cả ngay hôm nay. Đi làm thực tế thường xuyên nhất là functional, regression và smoke testing. Còn lại gặp đến đâu học đến đó.
Manual testing khác automation testing thế nào?
Câu hỏi mình hay nhận được nhất từ người mới: "Học automation cho nhanh đi, manual lỗi thời rồi?"
Không phải vậy. Hai thứ này không cạnh tranh nhau - chúng bổ trợ cho nhau.
| Tiêu chí | Manual testing | Automation testing |
|---|---|---|
| Thực hiện | Người bấm tay | Script/tool tự chạy |
| Tốc độ | Chậm hơn | Nhanh hơn (sau khi viết script) |
| Chi phí ban đầu | Thấp | Cao (cần viết script, maintain) |
| Phát hiện bug UX | Tốt | Kém |
| Phù hợp khi | Test mới, exploratory, UX | Regression, load test, lặp lại nhiều |
| Yêu cầu kỹ năng | Logic, tỉ mỉ, domain knowledge | Coding + manual foundation |
Manual và automation không thay thế nhau - dự án thật cần cả hai
Dùng manual khi:
- Tính năng vừa làm xong, chưa có script
- Test về giao diện (UI/UX) - máy không cảm nhận được "nhìn xấu" hay "khó dùng"
- Exploratory testing - cần tư duy con người
- Dự án nhỏ, chi phí viết automation cao hơn lợi ích
Dùng automation khi:
- Regression testing lặp đi lặp lại nhiều lần
- Load testing, performance testing
- Tính năng ổn định, ít thay đổi
- Team lớn, cần test nhanh sau mỗi lần deploy
Thực tế ở hầu hết công ty: dự án dùng cả hai. Manual tester kiểm tra tính năng mới, viết test case; automation engineer viết script để chạy regression tự động đêm. Không phải "dùng automation là bỏ manual".
Tại sao fresher nên học manual trước?
Mình đã thấy không ít bạn mới hỏi về Selenium, Cypress chưa đầy tuần sau khi bắt đầu học testing. Không phải sai - nhưng mà... bạn đang học lái xe số tự động khi chưa biết tay lái là gì.
Có 3 lý do cụ thể:
1. Manual là nền tảng để automation có nghĩa
Automation testing về bản chất là viết code để làm thay bạn những gì bạn làm bằng tay. Nếu bạn chưa biết mình đang làm gì bằng tay - thì code không giúp được gì. Script Selenium có thể bấm nút, nhập text, kiểm tra kết quả - nhưng bạn phải hiểu kết quả nào là đúng, kịch bản nào cần test, edge case nào không được bỏ. Kiến thức đó đến từ manual.
2. Bug logic và UX chỉ mắt người mới thấy
Tool automation chỉ biết "có xuất hiện element X không" hoặc "text có khớp không". Còn những thứ như: button quá nhỏ khó bấm, thông báo lỗi viết khó hiểu, flow thanh toán gây nhầm lẫn - chỉ con người mới cảm nhận được. Đây là kỹ năng tester cần xây dựng từ đầu.
Automation chạy nhanh, nhưng không cảm nhận được trải nghiệm người dùng
3. Phần lớn công ty tuyển junior tester cần manual trước
Mình xem qua nhiều JD tuyển tester fresher: phần lớn JD tuyển fresher tester chỉ yêu cầu manual testing tốt, automation là điểm cộng. Automation là điểm cộng, không phải bắt buộc ở level junior. Nghĩa là bạn hoàn toàn có thể xin việc với manual testing tốt.
Và đây là điều mình hay nói với học viên: học manual kỹ 6-12 tháng đầu, bạn sẽ hiểu tại sao cần test cái gì, khi nào cần test, edge case ở đâu. Lúc đó học automation sẽ nhanh hơn nhiều vì bạn chỉ cần học thêm "cách làm tự động" thôi - không cần học lại tư duy testing từ đầu.
Thấy khó hay lo lắng ở bước này là bình thường. Lớp mình có bạn 32 tuổi từ ngành kế toán, mất 3 tháng để quen với tư duy testing - nhưng giờ đã là senior tester ở một công ty outsource. Không cần biết code để bắt đầu. Chỉ cần logic và tỉ mỉ.
Kỹ năng cần có để làm manual tester
Có một điều mình hay nhấn mạnh: manual testing không cần biết code, nhưng cần một bộ kỹ năng khác - và những kỹ năng này nhiều người trái ngành đã có sẵn mà không biết.
Kỹ năng kỹ thuật
- Đọc hiểu requirement: biết phân tích tài liệu đặc tả (specification) để hiểu phần mềm cần làm gì. Kỹ năng đọc kỹ, không bỏ sót - người từ ngành văn phòng, kế toán thường khá tốt ở điểm này.
- Viết test case: liệt kê đầy đủ các kịch bản cần test, gồm happy path (trường hợp bình thường), invalid input (nhập sai), edge case (biên).
- Viết bug report: mô tả bug đủ để dev tái hiện được. Bug report thiếu thông tin = dev không fix được = bug tồn tại mãi.
- Dùng tool cơ bản: Jira để quản lý bug và task, TestRail hoặc Google Sheets để quản lý test case, Postman để test API cơ bản (cái này học sau cũng được).
Test case viết kỹ giúp cả team hiểu đã test những gì - không phải chỉ để báo cáo
Kỹ năng mềm - quan trọng không kém
- Tư duy phân tích: nhìn một tính năng và tự hỏi "cái gì có thể sai?", "user sẽ làm gì mà dev không nghĩ đến?"
- Tỉ mỉ, kiên nhẫn: test đi test lại cùng một thứ mà không bỏ sót. Không phải ai cũng làm được điều này - đây thật ra là lợi thế cạnh tranh.
- Giao tiếp rõ ràng: làm việc với dev, BA (business analyst), PM hàng ngày. Cần diễn đạt bug rõ ràng, không gây hiểu lầm.
- Tư duy "phá hoại" có kiểm soát: luôn tự hỏi "cách nào để làm cái này hỏng?" - kiểu tư duy này giúp tìm được bug mà happy path không phát hiện.
Bạn từng làm kế toán, giáo viên, nhân viên văn phòng? Kỹ năng tỉ mỉ, đọc tài liệu kỹ, giao tiếp rõ ràng - bạn đã có rồi. Cần học thêm là cách áp dụng vào testing mà thôi.
Lộ trình từ manual sang automation
Manual không phải điểm dừng - đó là điểm xuất phát. Phần lớn automation engineer đều đi qua con đường manual testing trước.
Lộ trình thực tế mà mình thấy ở nhiều người trong ngành:
Giai đoạn 1 - Học manual nền tảng (3-6 tháng) Tập trung vào: viết test case, bug report, hiểu SDLC (vòng đời phát triển phần mềm), làm quen Jira, học functional và regression testing. Mục tiêu: có thể xin việc junior tester.
Giai đoạn 2 - Thực hành tại công ty (6-12 tháng) Làm manual testing thật, tiếp xúc với dự án thật, học cách làm việc với dev và BA. Giai đoạn này quan trọng vì bạn sẽ thấy mình cần gì trong automation - không phải học lý thuyết chay.
Giai đoạn 3 - Học automation (từ tháng 12 trở đi) Bắt đầu với API testing (Postman, RestAssured), rồi UI automation (Selenium WebDriver hoặc Playwright). Lúc này bạn đã có tư duy testing - chỉ cần thêm kỹ năng coding.
Không cần vội - lộ trình rõ ràng giúp bạn tiến đều hơn là nhảy cóc
Bạn không nhất thiết phải theo đúng timeline này. Có người nhanh hơn, có người cần thêm thời gian. Điều quan trọng là đừng nhảy sang automation khi chưa vững manual - không phải vì ai cấm, mà vì bạn sẽ thấy khó hiểu và dễ nản.
Nếu bạn muốn có lộ trình học testing bài bản từ đầu với hướng dẫn rõ ràng, có thể tham khảo thêm các tài nguyên học testing từ cộng đồng cộng đồng Testing Việt Nam.
Và khi bạn sẵn sàng học automation, SQL là một trong những thứ cần biết để test database - kỹ năng này dùng được cả trong manual lẫn automation testing.
