Các Loại Test Cơ Bản: Functional, Non-Functional, Regression Là Gì?
6 tháng trước · 11 phút đọc
Tại sao cần phân biệt các loại test?
Mình nhớ hồi mới vào nghề, ai hỏi "bạn test gì?" là mình trả lời ngay: "Test xem nó chạy được không." Đúng nhưng chưa đủ - và thực ra là đang bỏ sót rất nhiều.
Thực tế, khi một app có bug production, team thường hỏi ngay: "Loại test nào cover case này?" Nếu bạn không phân biệt được functional test với regression test, bạn sẽ không biết mình đang thiếu gì trong quy trình.
Mỗi loại test bắt được một kiểu lỗi khác nhau - bỏ sót loại nào là bỏ sót cả nhóm bug đó
Bài này mình phân loại 4 nhóm test cơ bản mà tester mới bắt buộc phải hiểu: functional, non-functional, regression, và UAT. Không cần nhớ thuộc lòng định nghĩa - quan trọng là biết khi nào dùng loại nào và tại sao.
Functional testing - kiểm tra "chạy đúng không?"
Đây là loại test phổ biến nhất, và có lẽ là thứ bạn đang làm hàng ngày mà chưa biết tên.
Functional testing (kiểm thử chức năng) kiểm tra xem tính năng có hoạt động đúng theo yêu cầu không. Không quan tâm bên trong code viết thế nào - chỉ quan tâm input vào, output ra có đúng không.
Functional test tập trung vào "làm đúng không" - không quan tâm "làm nhanh không"
Ví dụ cụ thể với trang đăng nhập Shopee:
- Nhập email đúng + mật khẩu đúng → phải vào được trang chủ
- Nhập sai mật khẩu → phải báo lỗi "Mật khẩu không đúng"
- Bỏ trống email → phải báo lỗi "Vui lòng nhập email"
- Nhập email không có @ → phải báo lỗi format
Mỗi dòng ở trên là một test case functional. Bạn đang verify: chức năng này có làm đúng việc nó cần làm không?
Functional test bao gồm nhiều kỹ thuật nhỏ hơn: smoke testing (kiểm tra nhanh app chạy được không - như bật điện thoại xem có sáng không), sanity testing (kiểm tra nhanh sau fix bug), và integration testing (kiểm tra các module ghép lại có hoạt động với nhau không). Nhưng điểm chung: đều hỏi "chức năng X có đúng không?".
Khi nào dùng? Gần như mọi lúc - mỗi tính năng mới, mỗi lần thay đổi logic nghiệp vụ, mỗi lần deploy.
Non-functional testing - kiểm tra "chạy tốt không?"
Chức năng đăng nhập chạy đúng rồi. Nhưng nếu 10.000 người cùng đăng nhập lúc 12h trưa Black Friday - app còn đứng không? Load bao nhiêu giây? Dữ liệu người dùng có bị lộ không?
Đó là câu hỏi của non-functional testing (kiểm thử phi chức năng).
Non-functional test mới phát hiện được những lỗi "ẩn" không nhìn thấy khi test bình thường
Non-functional không kiểm tra "làm đúng không" mà kiểm tra "làm tốt không" - bao gồm:
- Performance testing: App load trong bao nhiêu giây? Chịu được bao nhiêu user đồng thời? (Ví dụ: trang thanh toán Tiki phải load dưới 3 giây)
- Security testing: Có lỗ hổng bảo mật không? Dữ liệu mã hóa chưa? (Ví dụ: password có lưu plain text không?)
- Usability testing: Người dùng có dùng được không? Có bị lạc không? (Ví dụ: button "Đặt hàng" có dễ tìm không?)
- Compatibility testing: Chạy tốt trên Chrome, Safari, Firefox không? iOS và Android không?
Với tester mới, bạn sẽ ít làm performance hay security test chuyên sâu - đó thường có team riêng hoặc tool chuyên biệt. Nhưng compatibility và usability thì bạn làm được ngay: test trên nhiều trình duyệt, nhiều thiết bị, quan sát flow người dùng có bị vướng không.
Lưu ý quan trọng: bug non-functional thường khó tìm hơn nhưng ảnh hưởng cực kỳ lớn. App chậm 3 giây là mất 50% (Think with Google) người dùng - không phải con số để bỏ qua.
Regression testing - kiểm tra "fix chỗ này, hỏng chỗ khác không?"
Đây là loại test mình từng bỏ qua nhiều nhất hồi mới đi làm - và đó là sai lầm tốn thời gian nhất.
Tình huống quen thuộc: Dev fix bug ở trang thanh toán. Bạn test lại, ổn. Deploy. Hôm sau nhận báo: tính năng thêm vào giỏ hàng bị lỗi. Không ai sửa giỏ hàng cả - nhưng nó vẫn hỏng. Tại sao?
Vì code thay đổi chỗ này đôi khi ảnh hưởng chỗ khác mà không ai ngờ tới.
Regression test chạy lại tính năng cũ sau mỗi thay đổi - phòng hơn chống
Regression testing (kiểm thử hồi quy) là test lại các tính năng cũ sau mỗi lần có thay đổi - dù thay đổi đó nhỏ đến đâu. Mục tiêu: đảm bảo code mới không làm hỏng thứ đã chạy đúng.
Ví dụ thực tế với app mobile giao đồ ăn:
- Dev thêm tính năng "lưu địa chỉ yêu thích" mới
- Regression test: kiểm tra lại luồng đặt hàng bình thường, thanh toán, theo dõi đơn, hủy đơn - tất cả các tính năng cũ
- Tại sao? Vì tính năng "địa chỉ" có thể ảnh hưởng đến luồng checkout
Regression test thường mất thời gian vì phải test nhiều. Đó là lý do sau này người ta dùng automation testing để tự động chạy lại. Nhưng với tester mới, bạn cần biết: mỗi lần có thay đổi là phải chạy lại ít nhất các tính năng liên quan.
Mình từng skip regression vì nghĩ "thay đổi nhỏ thôi, không ảnh hưởng đâu". Kết quả: bug nổ production, mất 2 ngày tìm nguyên nhân. Từ đó mình không bao giờ bỏ bước này nữa.
UAT - người dùng thật kiểm tra lần cuối
App đã test functional, non-functional, regression - mọi thứ ổn. Nhưng còn một câu hỏi chưa ai trả lời: "Người dùng thật có dùng được không?"
UAT (User Acceptance Testing) - kiểm thử chấp nhận người dùng - là giai đoạn cuối trước khi release chính thức. Không phải tester hay dev test, mà là đại diện người dùng thực tế (hoặc khách hàng) ngồi dùng thử và confirm "Cái này đúng với tôi cần".
UAT là "bộ lọc cuối" - tester kiểm tra kỹ thuật, người dùng kiểm tra thực tế
Ví dụ: Công ty phát triển phần mềm quản lý kho cho siêu thị. Tester đã test hết - mọi tính năng chạy đúng spec. Nhưng UAT: nhân viên kho thật ngồi dùng 2 ngày. Phát hiện: màn hình "nhập hàng" hiển thị quá nhiều cột, nhân viên phải cuộn ngang liên tục, chậm hơn Excel cũ. Không phải bug kỹ thuật, nhưng người dùng không chấp nhận.
UAT thường do Business Analyst (BA) hoặc Product Owner tổ chức. Tester đôi khi hỗ trợ chuẩn bị test scenario, ghi nhận feedback, log bug phát sinh.
Với tester mới, bạn ít khi làm UAT độc lập - nhưng hiểu khái niệm quan trọng vì:
- Biết tại sao có giai đoạn này trong quy trình
- Biết bug từ UAT thường là bug về UX/nghiệp vụ, không phải kỹ thuật
- Biết cách ghi nhận feedback từ người dùng thành bug report rõ ràng
Khi nào dùng loại test nào? Bảng so sánh nhanh
Biết định nghĩa chưa đủ - quan trọng hơn là biết áp dụng đúng lúc. Mình tổng hợp thành bảng để bạn dễ tra cứu:
| Loại test | Câu hỏi chính | Dùng khi nào | Ai làm? |
|---|---|---|---|
| Functional | Chạy đúng không? | Tính năng mới, mọi sprint | Tester |
| Non-functional | Chạy tốt không? | Trước release lớn, khi có yêu cầu performance/security | Tester chuyên biệt / team riêng |
| Regression | Fix rồi có hỏng cũ không? | Sau mỗi lần fix bug, mỗi lần deploy | Tester |
| UAT | Người dùng có chấp nhận không? | Trước release chính thức | BA, PO, đại diện khách hàng |
Chọn đúng loại test = tìm đúng loại bug - không phải test nhiều hơn là tốt hơn
Thực tế trong một sprint làm việc:
- Dev code xong tính năng → bạn chạy functional test
- Dev fix bug → bạn verify fix đúng + chạy regression các tính năng liên quan
- Chuẩn bị release → team chạy non-functional (performance, compatibility)
- Khách hàng duyệt → UAT
Không phải lúc nào cũng đủ cả 4 bước. Project nhỏ, startup có thể bỏ qua một số bước. Nhưng biết khi nào nên bỏ và hậu quả của việc bỏ - đó mới là kinh nghiệm thật sự.
Checklist chọn loại test phù hợp cho tester mới
Đây là công cụ thực hành giúp bạn tự quyết định - không cần hỏi senior mỗi lần.
Câu hỏi xác định loại test cần làm:
- Đây là tính năng mới chưa test lần nào? → Functional test trước
- Vừa có fix bug hoặc deploy code mới? → Regression test các tính năng liên quan
- Sắp release lớn, có nhiều user dùng? → Nhắc team kiểm tra performance/compatibility
- Khách hàng chưa xác nhận yêu cầu cuối? → Cần tổ chức UAT
In ra dán gần màn hình - checklist nhỏ giúp không bỏ sót bước nào
Tải về checklist đầy đủ tại đây: Tải checklist chọn loại test (interactive)
Một điểm mình muốn nhấn mạnh: bạn không cần làm cả 4 loại cho mỗi tính năng nhỏ. Fix typo trên giao diện thì không cần regression test toàn bộ app. Nhưng sửa logic tính tiền thì bắt buộc regression test luồng thanh toán.
Phán đoán đó đến từ kinh nghiệm - và kinh nghiệm đến từ việc thực hành, mắc lỗi, rồi rút ra bài học. Đừng lo nếu bạn chưa biết cân đối ngay từ đầu. Mình cũng phải học điều đó qua nhiều sprint.
Nếu bạn muốn học bài bản từ đầu về kiểm thử phần mềm - từ cách viết test case, bug report cho đến regression testing - khóa Kiểm thử phần mềm có đủ lộ trình từ zero đến có việc làm, phù hợp với bạn trái ngành chuyển sang.