Phân loại kiểm thử theo nhóm

Các loại kiểm thử phần mềm thường được phân theo ba nhóm chính: theo cấp độ (unit, integration, system, acceptance/UAT), theo mục đích (functional và non-functional), và theo góc nhìn kỹ thuật (black-box và white-box). Ngoài ra còn một nhóm liên quan đến thay đổi: smoke, sanity, retest (confirmation) và regression.

Mấu chốt khiến người mới rối là: một bài test có thể mang nhiều tên cùng lúc, vì nó được gọi theo các trục phân loại khác nhau. Ví dụ "test đăng nhập trên toàn hệ thống bằng cách nhập liệu mà không cần biết code" đồng thời là system test (theo cấp độ), functional (theo mục đích) và black-box (theo góc nhìn). Khi bạn hình dung mỗi loại test như một điểm trên ba trục tọa độ này, mọi thuật ngữ đều có chỗ đứng rõ ràng (theo cách phân loại của chuẩn quốc tế ISTQB).

Trong phần còn lại của bài, ta sẽ đi lần lượt từng nhóm — kèm bảng và ví dụ với "Hệ thống đặt phòng họp nội bộ" để bạn dễ liên hệ.

Functional vs Non-functional testing

Đây là cách phân loại theo mục đích: kiểm thử cái gì hay tốt tới đâu.

Tiêu chí Functional Testing Non-functional Testing
Trả lời câu hỏi Hệ thống làm ĐÚNG chức năng không Hệ thống chạy TỐT tới đâu
Dựa trên Yêu cầu chức năng Đặc tính chất lượng (ISO/IEC 25010)
Ví dụ Đăng nhập, đặt phòng, thanh toán đúng Hiệu năng, bảo mật, khả dụng, tương thích, độ tin cậy
Người mới làm Phần lớn bắt đầu ở đây Thường cần công cụ/chuyên môn riêng

Ví dụ với hệ thống đặt phòng họp: functional là kiểm tra đặt phòng có thành công không, có chống đặt trùng giờ không. Còn non-functional trả lời những câu hỏi "chất lượng" đi kèm, ví dụ:

  • Hiệu năng (performance): hệ thống chịu được 500 người đặt phòng cùng lúc không?
  • Bảo mật (security): có chặn được truy cập trái phép vào lịch phòng của người khác không?
  • Khả dụng (usability): người dùng mới có đặt phòng được mà không cần hướng dẫn không?
  • Tương thích (compatibility): chạy ổn trên Chrome, Safari, điện thoại không?

Người mới thường bắt đầu từ functional vì gần với nghiệp vụ và không cần công cụ chuyên sâu; non-functional thường cần kỹ năng và công cụ riêng (ví dụ JMeter cho performance).

Regression, Smoke, Sanity, Retest

Nhóm này phân loại theo mối liên hệ với thay đổi — rất hay dùng mỗi khi có build mới hoặc bug được sửa:

Loại Mục đích
Smoke test Kiểm tra rộng–nông xem build có đủ ổn để test tiếp không
Sanity test Kiểm tra hẹp–sâu một chức năng/bản sửa cụ thể
Retest (Confirmation) Chạy lại đúng test đã fail để xác nhận bug đã được sửa
Regression Kiểm tra thay đổi có làm hỏng phần đang chạy tốt không

Hình dung qua một tình huống quen thuộc: dev gửi build mới → tester chạy smoke xem app có "sống" không; build ổn, dev báo đã sửa bug đăng nhập → tester chạy sanity quanh vùng đó; xác nhận đúng cái bug cũ đã hết bằng retest (xem vòng đời của bug); cuối cùng, trước khi release, chạy regression để chắc thay đổi không kéo theo lỗi mới ở nơi khác.

Phân biệt dễ nhầm nhất: retest xác nhận lỗi cũ đã hết, còn regression đảm bảo không phát sinh lỗi mới. Smoke và sanity là hai "cánh cổng" trước khi test sâu — chi tiết ở bài smoke test vs sanity test. Vì regression phải lặp lại nhiều, nó là ứng viên hàng đầu để tự động hóa.

Black-box vs White-box

Đây là cách phân loại theo góc nhìn vào hệ thống khi thiết kế test:

Tiêu chí Black-box (hộp đen) White-box (hộp trắng)
Góc nhìn Không cần biết code, dựa trên đặc tả Dựa trên cấu trúc code bên trong
Kỹ thuật Phân vùng tương đương, giá trị biên, decision table Statement coverage, branch coverage
Ai thường làm Tester (manual rất phổ biến) Dev hoặc tester biết code
Ví dụ Nhập email sai định dạng xem báo lỗi không Kiểm tra mọi nhánh if/else đã được chạy

Ngoài hai nhóm trên, ISTQB còn nhắc tới kỹ thuật dựa trên kinh nghiệm (experience-based) như exploratory testing (kiểm thử khám phá), error guessing (đoán lỗi dựa kinh nghiệm) và checklist-based testing. Đây là vũ khí lợi hại của tester lâu năm: dùng trực giác và kinh nghiệm để "đánh hơi" những chỗ phần mềm hay hỏng mà test case viết sẵn dễ bỏ sót.

Người mới thường bắt đầu với black-box vì không yêu cầu lập trình; white-box đòi hỏi đọc hiểu code và thường gắn với cấp độ unit/integration.

Unit / Integration / System / UAT

Đây là cách phân loại theo cấp độ kiểm thử (test level) — đi từ nhỏ đến lớn trong vòng đời phát triển:

Cấp độ Test cái gì Ai thường thực hiện
Unit (Component) Từng đơn vị code nhỏ nhất (hàm, class) Dev
Integration Tương tác giữa các thành phần/module Dev / Tester
System Toàn bộ hệ thống đã tích hợp Tester
Acceptance (UAT) Hệ thống đáp ứng đúng nhu cầu nghiệp vụ Khách hàng / end user

Diễn giải nhanh từng cấp độ:

  • Unit: kiểm tra một hàm tính tiền phòng theo giờ trả về đúng kết quả chưa — do dev viết, chạy rất sớm.
  • Integration: kiểm tra module đặt phòng gọi đúng sang module lịch và gửi thông báo chưa.
  • System: chạy thử cả luồng nghiệp vụ trên hệ thống đã ghép — đây là nơi manual tester làm việc nhiều nhất.
  • Acceptance (UAT): khách hàng/end user nghiệm thu xem phần mềm có giải quyết đúng nhu cầu thực tế trước khi go-live.

Manual tester thường tham gia nhiều nhất ở cấp System và hỗ trợ chuẩn bị cho UAT.

Bảng tổng hợp khi nào dùng loại nào

Để bạn tra nhanh, đây là bảng "tình huống → loại test phù hợp":

Tình huống Loại test nên dùng
Vừa nhận một build mới từ dev Smoke test
Vừa sửa xong một bug nhỏ Sanity test / Retest
Trước release, sau nhiều thay đổi Regression test
Kiểm tra chức năng đúng yêu cầu Functional test
Kiểm tra tốc độ, tải, bảo mật Non-functional test
Kiểm tra một hàm/đơn vị code riêng lẻ Unit test
Nghiệm thu cùng khách hàng trước go-live Acceptance test (UAT)

Gặp thuật ngữ chưa rõ, bạn tra nhanh ở thuật ngữ kiểm thử.