Hồi mới vào nghề, mình từng tưởng "kiểm thử" chỉ là ngồi bấm thử app xem có lỗi không. 🙂 Đến khi đọc syllabus ISTQB mình mới vỡ lẽ: kiểm thử được chia thành nhiều tầng rất rõ ràng, mỗi tầng có người làm và mục tiêu riêng. Bài này mình kể cho bạn nghe gọn gàng về các cấp độ kiểm thử — từ unit tới UAT — để bạn nắm được bức tranh tổng thể, biết mình đang đứng ở đâu trong quy trình.

Các cấp độ kiểm thử theo ISTQB: unit, integration, system, acceptance UAT

Cấp độ kiểm thử (test levels) là gì?

Các cấp độ kiểm thử (test levels) theo ISTQB gồm 4 tầng: Unit (component), Integration, System và Acceptance (UAT). Mỗi cấp độ kiểm tra phần mềm ở một mức độ "lắp ráp" khác nhau — từ một hàm code nhỏ, tới các module ghép lại, tới cả hệ thống hoàn chỉnh, và cuối cùng là nghiệm thu theo nhu cầu người dùng. Đây là 4 nhóm hoạt động kiểm thử được tổ chức và quản lý cùng nhau.

Hiểu nôm na: bạn không kiểm thử "tất tần tật một lúc". Bạn đi từ chi tiết nhỏ nhất rồi nới rộng dần. Càng lên cấp cao, bạn càng nhìn phần mềm giống mắt người dùng cuối. Cách phân tầng này khớp với mô hình chữ V (V-model): mỗi cấp độ kiểm thử "soi gương" với một giai đoạn phát triển — unit ứng với thiết kế chi tiết, integration ứng với thiết kế kiến trúc, system ứng với đặc tả yêu cầu, và acceptance ứng với nhu cầu nghiệp vụ ban đầu.

Để dễ hình dung, suốt bài mình lấy ví dụ một Hệ thống đặt phòng họp nội bộ của công ty — kiểu app cho nhân viên chọn phòng, chọn khung giờ, gửi lời mời. Ta sẽ đi qua từng cấp độ với chính hệ thống này.

Unit testing

Unit test là gì? Đó là cấp độ kiểm thử nhỏ nhất — kiểm tra từng đơn vị code riêng lẻ (một hàm, một method, một class) một cách độc lập. Mục tiêu là xác nhận từng "viên gạch" hoạt động đúng trước khi ghép chúng lại. Unit testing còn được ISTQB gọi là component testing.

Trong Hệ thống đặt phòng họp, một unit có thể là hàm kiemTraTrungLich(phong, gioBatDau, gioKetThuc) — chỉ làm đúng một việc: trả về true nếu khung giờ bị trùng. Bạn viết test cho riêng hàm này, không cần database hay giao diện, thường dùng mock/stub để giả lập phần phụ thuộc.

  • Ai làm: lập trình viên (developer) là người viết và chạy unit test, thường ngay trong lúc code.
  • Khi nào: sớm nhất, ngay khi một đơn vị code vừa hoàn thành.
  • Mục tiêu: bắt lỗi logic ở mức nhỏ nhất, nơi sửa rẻ nhất.

Unit test thường gắn với TDD (Test-Driven Development) và được tự động hóa cao bằng các framework như JUnit, NUnit, pytest. Đây là cấp độ tester thủ công ít đụng tới nhất, nhưng hiểu nó giúp bạn phối hợp với dev tốt hơn.

Integration testing

Integration test (kiểm thử tích hợp) kiểm tra cách các đơn vị/module đã qua unit test giao tiếp và hoạt động cùng nhau. Một hàm chạy đúng khi đứng riêng chưa chắc đã đúng khi ghép với hàm khác — lỗi thường nằm ở "đường nối" giữa chúng: sai định dạng dữ liệu truyền qua, gọi API sai thứ tự, hiểu nhầm giá trị trả về.

Ở Hệ thống đặt phòng họp, integration testing kiểm tra ví dụ: module "Đặt phòng" gọi sang module "Gửi thông báo" — khi đặt thành công thì email mời họp có được kích hoạt với đúng dữ liệu phòng và giờ không? Hay module đặt phòng có ghi đúng vào database lịch không?

ISTQB phân biệt hai loại tích hợp: component integration (ghép các module trong cùng một hệ thống) và system integration (ghép hệ thống của bạn với hệ thống ngoài, ví dụ tích hợp với Google Calendar). Về cách tiếp cận, có ba lối quen thuộc:

Cách tích hợp Ý tưởng
Top-down Ghép từ module cấp cao xuống thấp, dùng stub thay phần chưa có
Bottom-up Ghép từ module cấp thấp lên cao, dùng driver để gọi
Big-bang Ghép tất cả một lúc rồi test — nhanh nhưng khó tìm nguyên nhân lỗi
  • Ai làm: developer và/hoặc tester, tùy mức tích hợp.
  • Khi nào: sau khi các unit liên quan đã pass.
  • Mục tiêu: phát hiện lỗi ở giao diện và tương tác giữa các thành phần.

System testing

System testing kiểm thử toàn bộ hệ thống đã được tích hợp hoàn chỉnh, đối chiếu với đặc tả yêu cầu (requirements). Đây là lần đầu phần mềm được nhìn như một khối thống nhất, trong môi trường gần giống thật. Tester là nhân vật chính ở cấp độ này.

Với Hệ thống đặt phòng họp, system testing kiểm tra trọn vẹn luồng nghiệp vụ end-to-end: nhân viên đăng nhập → tìm phòng trống → đặt phòng → nhận xác nhận → người được mời thấy lịch. Đồng thời, đây là nơi kiểm tra cả yêu cầu phi chức năng: tốc độ tải trang (performance), bảo mật phân quyền (security), khả năng dùng được (usability).

  • Ai làm: đội kiểm thử độc lập (independent test team).
  • Khi nào: sau khi integration xong, hệ thống đã hoàn chỉnh.
  • Mục tiêu: xác nhận hệ thống đáp ứng cả yêu cầu chức năng lẫn phi chức năng theo đặc tả.

System testing nên chạy trong môi trường test riêng, cấu hình càng giống production càng tốt, để kết quả phản ánh đúng thực tế khi go-live.

Acceptance testing (UAT)

UAT là gì? Acceptance testing (kiểm thử chấp nhận) là cấp độ cuối, xác nhận hệ thống đáp ứng nhu cầu nghiệp vụ và sẵn sàng bàn giao — do người dùng/khách hàng thực hiện, không phải đội kỹ thuật. UAT (User Acceptance Testing) là dạng phổ biến nhất, nhưng acceptance testing rộng hơn UAT.

Khác biệt cốt lõi với system testing: system testing hỏi "phần mềm có đúng đặc tả không?", còn acceptance testing hỏi "phần mềm có giải quyết được công việc thật của người dùng không?". Ở Hệ thống đặt phòng họp, chính nhân viên hành chính — người dùng thật — sẽ tự đặt thử vài cuộc họp theo kịch bản công việc hằng ngày để xác nhận app dùng được, trước khi công ty triển khai rộng.

ISTQB liệt kê vài dạng acceptance testing đáng nhớ:

  • UAT (User Acceptance Testing): người dùng cuối kiểm tra hệ thống có phục vụ đúng nhu cầu nghiệp vụ.
  • OAT (Operational Acceptance Testing): đội vận hành kiểm tra backup, phục hồi, bảo trì, cài đặt.
  • Contractual & regulatory acceptance: nghiệm thu theo điều khoản hợp đồng hoặc quy định pháp lý.

  • Alpha & beta testing: alpha do người dùng test tại nơi nhà phát triển; beta do người dùng test tại môi trường của họ.

  • Ai làm: khách hàng, người dùng cuối, đội vận hành.

  • Khi nào: sau system testing, ngay trước khi go-live.
  • Mục tiêu: tạo niềm tin để bàn giao; phát hiện vấn đề về sự phù hợp với nhu cầu thực.

Bảng so sánh 4 cấp độ (ai làm · khi nào · mục tiêu)

Đây là bảng mình hay vẽ lại cho học viên để nhớ nhanh các cấp độ kiểm thử:

Cấp độ Test gì Ai làm Khi nào Ví dụ (Hệ thống đặt phòng họp)
Unit (component) Một đơn vị code riêng lẻ Developer Vừa code xong Hàm kiểm tra trùng lịch phòng
Integration Tương tác giữa các module Dev / Tester Sau khi unit pass Module đặt phòng gọi module gửi email
System Toàn hệ thống vs đặc tả Đội test độc lập Sau integration Luồng đặt phòng end-to-end + hiệu năng, bảo mật
Acceptance (UAT) Hệ thống vs nhu cầu thật Người dùng / khách hàng Trước go-live Nhân viên hành chính đặt thử cuộc họp thật

Mẹo nhớ: đi từ trên xuống là đi từ nhỏ → lớn, từ góc nhìn dev → góc nhìn người dùng, và lỗi bắt được càng muộn thì sửa càng đắt. Đó là lý do ai cũng khuyên "test sớm, test thường xuyên".

Phân biệt test levels vs test types

Đây là chỗ rất nhiều bạn mới nhầm, nên mình tách riêng. Test levels (cấp độ kiểm thử) trả lời câu hỏi "kiểm thử ở giai đoạn nào / mức lắp ráp nào" (unit, integration, system, acceptance). Còn test types (loại kiểm thử) trả lời "kiểm thử khía cạnh gì" (functional, performance, security, usability...).

Hai khái niệm này trực giao — tức là độc lập và kết hợp được với nhau. Bạn có thể chạy functional test (một test type) ở system level (một test level); cũng có thể chạy performance test ở cấp system. Một cái nói về khi nào / lắp ráp tới đâu, cái kia nói về soi khía cạnh nào.

Để nắm trọn bức tranh, bạn nên đọc thêm bài các loại kiểm thử (phần test types) song song với bài này. Hai cấp độ và loại kiểm thử này đều nằm trong quy trình kiểm thử STLC tổng thể, và đều là kiến thức cốt lõi trong ISTQB là gì. Nếu gặp thuật ngữ lạ trong lúc đọc, tra nhanh ở thuật ngữ kiểm thử cho chắc.

Muốn học bài bản các cấp độ kiểm thử cùng toàn bộ syllabus và luyện thi CTFL có người hướng dẫn, bạn có thể tham khảo khóa chứng chỉ ISTQB CTFL của IT LEARN.