System Integration Testing(SIT)
Giai đoạn kiểm thử ghép các hệ thống hoặc module lại với nhau để xem dữ liệu chạy qua ranh giới giữa chúng có đúng không. Đây là nơi lộ ra phần lớn lỗi tích hợp trước khi tới tay người dùng.
Định nghĩa
Từng module chạy ngon lành khi test riêng. Ghép lại thì tiền trừ hai lần, hoặc đơn hàng sang kho mất trường mã chi nhánh. SIT sinh ra để bắt đúng loại lỗi đó — lỗi nằm ở chỗ nối, không nằm trong ruột từng hệ thống.
SIT kiểm tra dòng dữ liệu và luồng nghiệp vụ đi xuyên qua nhiều hệ thống, do đội kỹ thuật chạy, trước khi khách chạm vào.
SIT bắt loại lỗi gì
- Sai định dạng ở ranh giới: hệ thống A gửi ngày
dd/MM/yyyy, hệ thống B đọc theoMM/dd/yyyy. Ngày 03/07 thành mùng 7 tháng 3. - Thiếu trường bắt buộc trong payload, hoặc trường bị cắt độ dài.
- Xử lý lỗi và timeout: bên kia không trả lời trong 30 giây thì mình làm gì, có retry không, retry có sinh bản ghi trùng không.
- Thứ tự nghiệp vụ: hủy đơn trước khi thanh toán được ghi nhận thì trạng thái cuối là gì.
Thêm một nhóm nữa hay bị bỏ quên vì nó không gây lỗi ngay: độ trễ đồng bộ dữ liệu master. Mã sản phẩm vừa tạo bên ERP thì bao lâu sau mới thấy được bên web bán hàng, và trong khoảng chờ đó nhân viên bán hàng nhìn thấy cái gì.
SIT và UAT khác nhau ở đâu
Bảng này nên thuộc, vì đây là chỗ BA hay bị khách hỏi vặn.
| Tiêu chí | SIT | UAT |
|---|---|---|
| Ai test | QC, đôi khi dev, BA hỗ trợ | Người dùng nghiệp vụ bên khách chạy và chủ trì, QC chỉ hỗ trợ tổ chức |
| Môi trường | Môi trường SIT, kết nối hệ thống bên thứ ba ở chế độ sandbox | Môi trường UAT, cấu hình gần giống PROD |
| Dữ liệu | Dữ liệu tự tạo, có cả case bẩn cố ý | Dữ liệu nghiệp vụ thật đã che thông tin nhạy cảm |
| Mục tiêu | Ghép đúng kỹ thuật, dữ liệu chạy thông | Đúng nghiệp vụ, dùng được ngoài đời |
| Tiêu chí pass | Hết Critical và High, các case bắt buộc pass | Khách ký biên bản nghiệm thu |
| Ai chịu trách nhiệm | Đội dự án | Khách hàng hoặc business owner |
Điểm dễ nhầm nhất: nhiều người tưởng UAT chỉ là chạy lại test case của SIT thêm một lượt. Nó khác hẳn. UAT chạy theo quy trình làm việc thật của người dùng, còn SIT chạy theo luồng dữ liệu giữa các hệ thống.
Một chỗ nữa hay nói ngược: người chủ trì UAT là phía nghiệp vụ hoặc bên mua, kể cả khi trên thực tế QC là người dựng kịch bản, chuẩn bị dữ liệu và ngồi cạnh cầm tay chỉ việc. Để QC đứng ra chủ trì là thói quen của thị trường, và đó chính là kiểu nghiệm thu mà khách ký xong vẫn nói hệ thống này không dùng được.
Ví dụ thực tế
Khách đặt đơn hai sản phẩm, thanh toán thành công. WMS báo hết hàng một món, đơn tự tách làm hai — và hệ thống gọi hoàn tiền cho cả đơn thay vì phần chênh lệch. Test riêng website, riêng WMS, riêng cổng thanh toán thì đều pass.
Đây là dự án tích hợp website bán lẻ với WMS và một cổng thanh toán, SIT kéo dài ba tuần, 4 hệ thống liên quan nếu tính cả ứng dụng giao hàng. Đội chạy 258 case cho luồng tích hợp, tìm được 41 defect, 12 cái nằm đúng ở chỗ nối giữa hai hệ thống — trong đó có cái hoàn tiền phía trên, thứ mà cả release suýt mang lên PROD.
Chuẩn bị SIT cho đỡ vỡ trận
- Chốt sớm danh sách interface: mỗi interface một dòng, ai gọi ai, đồng bộ hay bất đồng bộ, ai chịu trách nhiệm phía bên kia.
- Xin tài khoản sandbox của bên thứ ba trước ít nhất hai tuần. Đây là thứ trễ nhiều nhất, đặc biệt với ngân hàng và đơn vị vận chuyển.
- Chuẩn bị dữ liệu test cho cả trường hợp xấu: mã hết hạn, số dư không đủ, đối tác trả về mã lỗi lạ.
- Thống nhất trước ai log defect cho hệ thống bên kia và thời gian phản hồi tối đa.
Việc của BA trong SIT
BA không phải người chạy test, nhưng là người bị gọi nhiều nhất. Bạn cần trả lời được: kỳ vọng đúng là gì khi hai hệ thống mâu thuẫn nhau, và bên nào là nguồn dữ liệu chuẩn. Chuẩn bị sẵn một sơ đồ luồng dữ liệu gọn một trang, dán vào Confluence, đỡ phải giải thích lại mười lần.
Nếu bên thứ ba chậm trả lời, đừng để defect nằm chờ im lìm. Ghi rõ đang chờ ai, hạn nào, rồi đẩy lên báo cáo hằng ngày. Cái gì không hiện lên báo cáo thì không ai xử lý.
