Một sản phẩm không tự nhiên mọc ra nguyên cục. Dev viết function, ghép function thành component, các component gọi nhau, nhiều service ghép thành hệ thống, cuối cùng hệ thống đó đi vào tay người dùng hoặc đội vận hành.
Test một function tính phí và test cả flow chuyển tiền rõ ràng không thể làm y hệt nhau. Đối tượng khác, lỗi muốn bắt khác, môi trường khác. Từ đấy mới sinh ra test level.
Test level là gì?
Test level là một nhóm hoạt động test được tổ chức và quản lý cùng nhau. Mỗi level gắn với một phiên bản nhất định của test object, từ phần nhỏ của code đến cả hệ thống trong bối cảnh sử dụng.
CTFL 4.0.1 dùng năm level:
- Component testing
- Component integration testing
- System testing
- System integration testing
- Acceptance testing
Bài cũ của mình gộp hai integration level thành Integration Test, cách nói vẫn rất phổ biến trong dự án. Lần này mình tách ra để khỏi có cảnh hai người cùng nói “integration” nhưng một người đang test giữa hai class, người kia đang test giữa app ngân hàng và cổng thanh toán.
V-Model là một cách dễ nhìn để ghép test level với sản phẩm làm việc tương ứng. Nó không có nghĩa mọi dự án phải chờ đi hết một nhánh rồi mới được test.
Component testing
Component testing, nhiều nơi gọi luôn là unit testing, kiểm tra một component trong trạng thái tương đối tách biệt. Component có thể là function, class, module hoặc một đơn vị lớn hơn tùy kiến trúc.
Giả sử có hàm tính phí:
def fee(amount):
if amount <= 0:
raise ValueError("amount must be positive")
return amount * 0.01Test ở level này quan tâm những thứ như:
- Input hợp lệ trả đúng kết quả.
- Boundary và input không hợp lệ được xử lý đúng.
- Exception đúng loại và đúng thời điểm.
- Các nhánh quan trọng của code đã được chạy.
Developer thường chịu trách nhiệm chính vì họ ở gần code nhất và sửa ngay tại chỗ. Tester có thể tham gia nếu team cần kỹ năng test hoặc có component test ở mức cao hơn. Chuyện quan trọng không phải đóng dấu “việc dev” hay “việc tester”, mà là component phải có hàng rào trước khi đem đi ghép.
Typical question: Who is responsible for component testing?
Developers usually own most component tests because they work closest to the code. Testers may also contribute depending on the product, skills and required independence.
Component integration testing
Hai component đứng riêng đều chạy ngon chưa nói được lúc gọi nhau chúng sẽ ngon.
Component A gửi amount dạng decimal, component B lại parse integer. Service này timeout sau 10 giây, client đã bỏ cuộc ở giây thứ 3. Bên gửi gọi field là userId, bên nhận chờ customer_id. Đấy là đất của component integration testing.
Các lỗi thường gặp:
- Sai format, encoding hoặc mapping dữ liệu.
- Gọi sai thứ tự hay sai thời điểm.
- Không xử lý timeout, retry hoặc partial failure.
- Hiểu khác nhau về contract và error response.
- State được cập nhật một nửa rồi bỏ dở.
Dev có thể test bằng unit/component test với fake, stub hoặc test container. Tester có thể test API hoặc một build tích hợp. Có frontend hay không không phải ranh giới quyết định ai được làm.
Big bang và incremental
Big bang ghép nhiều phần rồi mới test một lượt. Setup ban đầu có vẻ đỡ việc, nhưng failure xuất hiện thì khoanh vùng thủ phạm rất mệt.
Incremental integration ghép dần từng phần. Nếu dependency chưa sẵn sàng, có thể dùng:
- Stub đứng ở phía được gọi và trả dữ liệu giả.
- Driver đứng ở phía gọi để kích hoạt component đang test.
- Service virtualization, fake server hoặc mock hiện đại cũng giải cùng họ vấn đề đó.
Ngày nay team thường tích hợp liên tục, nhưng chữ CI không tự đảm bảo integration test tốt. Pipeline xanh chỉ chứng minh những test đã được viết đang xanh.
System testing
System testing kiểm tra hành vi và đặc tính của cả hệ thống tương đối hoàn chỉnh. Test basis có thể gồm requirement, user story, use case, risk, specification và cả luật mà team đã thống nhất.
Ở level này ta nhìn thấy những flow kiểu:
- Đăng ký → xác minh email → đăng nhập.
- Tạo đơn → thanh toán → trừ tồn kho → gửi thông báo.
- Phân quyền giữa user, moderator và admin.
- Performance, security, usability hoặc compatibility của hệ thống.
Một nhóm test độc lập thường làm phần lớn system testing vì góc nhìn tách khỏi implementation rất có ích. Nhưng “chỉ tester mới thực hiện System Test” là câu nói quá tay. Developer, specialist hoặc team khác vẫn có thể tham gia; context và mức độc lập cần thiết mới quyết định.
Typical question: What is system testing?
System testing verifies the behavior and quality characteristics of a complete system against its test basis in an environment representative of its intended use.
System integration testing
System integration testing kiểm tra giao diện giữa hệ thống đang test với hệ thống khác hoặc external service.
Ví dụ app thương mại điện tử gọi payment gateway:
- Request thanh toán có đúng contract không?
- Gateway trả success nhưng callback đến chậm thì đơn hàng ở state nào?
- Callback bị gửi hai lần có trừ tiền hoặc tạo đơn hai lần không?
- Gateway chết, app retry thế nào và người dùng nhìn thấy gì?
Đoạn này hay bị gom vào integration test hoặc system test, hoàn toàn bình thường. Khi scope lớn lên, tách tên ra giúp team nói rõ đang test bên trong một hệ thống hay đường nối giữa nhiều hệ thống.
Acceptance testing
Acceptance testing đánh giá hệ thống đã sẵn sàng để được chấp nhận, triển khai hoặc sử dụng hay chưa. Nó tập trung vào nhu cầu business, quy trình vận hành, nghĩa vụ hợp đồng hoặc quy định — tùy context.
Người tham gia có thể là end user, khách hàng, Product Owner, đại diện business, đội vận hành hoặc cơ quan có thẩm quyền. Tester thường hỗ trợ môi trường, data, scenario và ghi nhận issue. Quyết định accept thuộc về phía có thẩm quyền chấp nhận, không tự động thuộc tester.
Các dạng thường gặp:
| Dạng | Trọng tâm |
|---|---|
| User acceptance testing | Người dùng hoặc business có hoàn thành được công việc thật không? |
| Operational acceptance testing | Backup, restore, monitoring, vận hành và hỗ trợ đã sẵn sàng chưa? |
| Contractual acceptance testing | Sản phẩm có đạt acceptance criteria trong hợp đồng không? |
| Regulatory acceptance testing | Sản phẩm có đáp ứng quy định liên quan không? |
| Alpha/Beta testing | Lấy feedback từ người dùng trong môi trường được kiểm soát hoặc ngoài thực tế |
UAT không phải buổi khách hàng bấm vài cái rồi ký vì deadline đã đến. Nếu acceptance criteria mơ hồ hoặc môi trường chẳng giống vận hành thật, chữ ký đó chỉ giúp đóng hồ sơ chứ không giúp hệ thống bớt rủi ro.
Có phải lúc nào cũng đi từ thấp lên cao?
Về mặt dependency, component phải tồn tại rồi mới ghép thành system. Nhưng hoạt động test không cần ngồi xếp hàng tuyệt đối.
Trong lúc dev viết component test, tester đã có thể review acceptance criteria, thiết kế system test, chuẩn bị data và contract test. Một số level chạy song song hoặc lặp lại nhiều lần theo từng increment. Đừng nhìn V-Model rồi biến nó thành thác nước bằng bê tông.
Chốt lại
| Level | Câu hỏi ngắn |
|---|---|
| Component | Phần riêng này có chạy đúng không? |
| Component integration | Các phần code ghép với nhau có đúng contract không? |
| System | Cả hệ thống có đáp ứng test basis không? |
| System integration | Hệ thống có nói chuyện đúng với hệ thống khác không? |
| Acceptance | Sản phẩm đã đủ để phía có thẩm quyền chấp nhận chưa? |
Biết level giúp xác định test object, mục tiêu, môi trường và người cần tham gia. Bài tiếp theo là Test Plan: trước khi test cả đống thứ này, team phải thống nhất scope, nguồn lực, rủi ro và điều kiện dừng đã.
