Manual Testing là gì? Tại sao người mới nên học manual trước automation
6 giờ tới · 11 phút đọc
Manual testing là gì?
Mình nhớ lần đầu nghe từ "manual testing", cứ nghĩ đơn giản là "ngồi click click rồi xem có lỗi không". Thực ra không sai, nhưng chưa đủ. Manual testing không phải click lung tung - mà là kiểm thử có kịch bản, có mục tiêu, có tiêu chí rõ ràng.
Manual testing (kiểm thử thủ công) là quá trình tester tự tay thực hiện các thao tác trên phần mềm, theo từng test case (kịch bản kiểm thử) đã viết sẵn, để tìm xem có bug nào không. Không dùng script, không dùng tool tự động - tất cả do con người thực hiện trực tiếp.
Manual testing: tester tự thao tác, quan sát, ghi nhận - không phụ thuộc vào script
Một ví dụ đơn giản: bạn đang test tính năng đăng nhập của ứng dụng. Manual testing nghĩa là bạn sẽ tự mở trình duyệt, tự gõ email, tự gõ mật khẩu, tự nhấn nút Login - rồi quan sát xem hệ thống phản hồi đúng không, có thông báo lỗi hợp lý không, có chuyển trang đúng không. Bạn làm việc này theo từng kịch bản: đúng thông tin, sai mật khẩu, bỏ trống email, nhập ký tự đặc biệt... mỗi kịch bản đó chính là một test case.
Nếu automation testing (kiểm thử tự động) là cỗ máy chạy theo lệnh đã lập trình sẵn, thì manual testing là người thật với đôi mắt và bộ não đang suy nghĩ - quan sát những thứ mà máy chưa được "dạy" để nhận ra.
Quy trình thực hiện manual testing
Không phải cứ mở app lên rồi click ngẫu nhiên là manual testing. Muốn test có giá trị, bạn cần đi theo quy trình - thiếu bước nào là dễ bỏ sót bug lắm.
Bước 1: Hiểu yêu cầu (requirement)
Trước khi test, phải biết tính năng đó làm gì. Đọc tài liệu đặc tả (requirement document), hỏi BA hoặc dev nếu chưa rõ. Tester không đọc kỹ requirement là nguồn gây ra rất nhiều bug bị bỏ sót - vì không biết "đúng" trông như thế nào.
Bước 2: Viết test case
Viết ra từng kịch bản cần kiểm thử: input là gì, thao tác như thế nào, kết quả mong đợi là gì. Đây là bước quan trọng nhất. Test case kỹ thì test mới kỹ.
Bước 3: Chuẩn bị môi trường test
Đảm bảo có đủ tài khoản test, dữ liệu mẫu, thiết bị cần thiết. Môi trường không ổn định sẽ làm kết quả test bị sai lệch.
Bước 4: Thực hiện test
Chạy từng test case theo đúng thứ tự, ghi lại kết quả thực tế so với kết quả mong đợi. Mình hay dùng Google Sheet hoặc tool như Jira Test Management để ghi cho tiện.
Bước 5: Báo cáo bug
Phát hiện bug thì viết bug report - mô tả rõ cách tái hiện, kết quả thực tế, kết quả mong đợi, attach screenshot hoặc video. Bug report mờ nhạt thì dev không fix được đâu.
Bước 6: Kiểm thử lại sau khi fix (retest)
Sau khi dev fix bug, bạn test lại đúng bug đó - và cũng chạy thêm kiểm thử hồi quy (regression testing), tức là test lại các tính năng liên quan để đảm bảo fix này không làm hỏng chỗ khác.
6 bước này là vòng lặp - không phải làm một lần rồi xong
Ví dụ thực tế: test tính năng login trên web
Lý thuyết nghe xong dễ quên. Mình ví dụ luôn cho dễ hình dung.
Tình huống: Bạn đang test tính năng đăng nhập của một trang web thương mại điện tử (giả sử như Shopee).
Bạn cần test những gì? Không chỉ "đăng nhập đúng là xong". Dưới đây là một phần test case mình sẽ viết:
| Test case | Input | Kết quả mong đợi |
|---|---|---|
| TC01 - Đăng nhập hợp lệ | Email đúng + password đúng | Vào trang chủ, hiển thị tên user |
| TC02 - Sai mật khẩu | Email đúng + password sai | Thông báo "Mật khẩu không đúng" |
| TC03 - Email không tồn tại | Email chưa đăng ký | Thông báo "Tài khoản không tồn tại" |
| TC04 - Bỏ trống email | Để trống + password bất kỳ | Thông báo "Vui lòng nhập email" |
| TC05 - Password ký tự đặc biệt | Email đúng + pass có @#$%^ | Đăng nhập thành công nếu đúng |
| TC06 - Nhập quá nhiều ký tự | Email 500 ký tự | Không crash, có thông báo phù hợp |
6 kịch bản login này mới chỉ là phần cơ bản - còn nhiều edge case hơn nữa
Mình từng chỉ test TC01 và TC02 rồi báo "done". Sau đó bug nổ production vì không ai test TC05 - password có ký tự đặc biệt bị hệ thống xử lý sai. Mất cả buổi chiều để tìm nguyên nhân. Từ đó mình học được: test case không kỹ là để lại rủi ro, không phải "xong việc".
Mỗi dòng trong bảng trên là một lần bạn tự ngồi thực hiện thao tác, quan sát kết quả, và ghi lại. Đó là manual testing.
Ví dụ thực tế: test flow thanh toán trên mobile
Thêm một ví dụ nữa với app mobile - vì cách test có đôi chỗ khác với web.
Tình huống: Test flow đặt hàng và thanh toán trên app mobile (giống Shopee hoặc Tiki).
Flow cần test gồm nhiều bước liên tiếp:
- Chọn sản phẩm → thêm vào giỏ hàng
- Vào giỏ hàng → chọn sản phẩm cần mua
- Chọn địa chỉ giao hàng
- Chọn phương thức thanh toán (thẻ/ví/COD)
- Nhấn "Đặt hàng"
- Kiểm tra màn hình xác nhận đơn hàng
Chỉ test "happy path" (luồng đi đúng, mọi thứ ổn) là chưa đủ. Bạn cần test thêm:
- Giỏ hàng rỗng: nhấn thanh toán mà không có sản phẩm nào → có thông báo phù hợp không?
- Sản phẩm hết hàng: sản phẩm trong giỏ hết stock trước khi checkout → app xử lý thế nào?
- Thanh toán thất bại: thẻ hết tiền hoặc lỗi kết nối → có thông báo và cho thử lại không?
- Mất mạng giữa chừng: đang thanh toán thì tắt wifi → đơn hàng có bị trùng không?
Flow thanh toán mobile có nhiều điểm rủi ro hơn bạn nghĩ
Test mobile còn cần chú ý thêm: thao tác bằng ngón tay (nút nhấn có đủ lớn không?), màn hình nhỏ (text có bị cắt không?), xoay ngang dọc (layout có vỡ không?). Đây là những thứ tester phát hiện được mà automation chưa chắc đã bắt được nếu không được cài đặt kiểm tra đặc biệt.
Mình khuyên bạn viết test case trước khi ngồi test, dù bài tập nhỏ hay app thật. Thói quen này giúp bạn không bị bỏ sót kịch bản quan trọng.
Ưu điểm và hạn chế của manual testing
Manual testing không phải là thứ hoàn hảo. Nhưng cũng không phải thứ lỗi thời. Mình thấy nhiều bạn mới hay cực đoan theo hướng nào đó - hoặc coi manual là "thủ công lạc hậu", hoặc ngại học automation vì "manual vẫn đủ". Cả hai đều chưa đúng.
Ưu điểm của manual testing:
- Phát hiện được những lỗi về UX, giao diện, cảm giác người dùng mà automation khó bắt
- Linh hoạt, không cần setup phức tạp - mở app lên là test được ngay
- Phù hợp với tính năng thay đổi nhanh, vì viết script automation tốn thời gian hơn
- Hiệu quả với exploratory testing (kiểm thử khám phá) - tức là test không theo kịch bản cứng, tự do khám phá bug lạ
- Dễ học, phù hợp người mới - không cần biết lập trình
Hạn chế của manual testing:
- Chậm nếu cần test lại nhiều lần (regression testing với 500 test case mà chạy tay là... rất mệt)
- Dễ bỏ sót khi test lặp lại nhiều vòng - con người mệt, mất tập trung
- Khó scale: một mình bạn không thể test 1.000 tình huống trong 1 giờ
- Kết quả phụ thuộc nhiều vào kỹ năng và sự tỉ mỉ của tester
Manual và automation bổ trợ nhau - không phải thay thế nhau
Thực tế trong team QA, không ai dùng chỉ manual hoặc chỉ automation. Tính năng mới thường test manual trước, sau khi ổn định mới viết script automation để chạy regression. Hai cái bổ trợ nhau, không loại trừ nhau.
Manual testing vs automation testing: học cái nào trước?
Đây là câu hỏi mình nhận nhiều nhất từ người mới chuyển ngành. Mình sẽ trả lời thẳng: học manual trước, không bàn cãi.
Vì sao? Mình giải thích bằng một ví von quen thuộc: bạn không thể học lái xe số tự động trước khi hiểu nguyên tắc lái xe. Automation testing là công cụ giúp tester làm nhanh hơn - nhưng nếu bạn không hiểu test gì, tại sao test, kịch bản nào quan trọng, thì script automation bạn viết cũng chỉ "chạy được" chứ không "test đúng".
| Tiêu chí | Manual testing | Automation testing |
|---|---|---|
| Yêu cầu kỹ thuật | Không cần lập trình | Cần biết code (Python, Java...) |
| Thời gian học | 1-3 tháng cơ bản | 3-6 tháng sau khi đã có nền manual |
| Phù hợp | Tính năng mới, UX, exploratory | Regression, test lặp lại nhiều lần |
| Chi phí setup | Thấp | Cần tool, môi trường, thời gian viết script |
| Phát hiện bug "lạ" | Tốt hơn | Khó nếu không được lập trình sẵn |
Manual là nền tảng - automation là công cụ mở rộng năng lực
Nếu bạn 25, 30, hay 35 tuổi trái ngành muốn vào testing - đừng lo vì không biết code. Rất nhiều tester làm manual rất giỏi mà không cần viết một dòng script nào. Sau khi hiểu rõ testing là gì, biết viết test case tốt, biết báo cáo bug chuẩn - lúc đó học automation sẽ nhanh hơn rất nhiều vì bạn đã có tư duy.
Mình từng thấy bạn học automation ngay từ đầu - code chạy được nhưng test case thiếu sót lung tung, bug vẫn lọt production vì không biết test cái gì cho đủ. Còn bạn học manual kỹ rồi chuyển sang automation - script viết ra đúng trọng tâm, coverage tốt hơn hẳn.