Kiểm thử luồng nghiệp vụ đầu-cuối (End-to-End Business Flow Testing) cho hệ bồi thường bảo hiểm xe

1. Tóm tắt nhanh & sơ đồ luồng bạn sẽ test

Nếu bạn đã quen kiểm thử từng chức năng riêng lẻ — form nhập liệu chạy đúng, API trả về đúng mã trạng thái, màn hình hiển thị đúng dữ liệu — bài này đưa bạn sang một góc nhìn khác hẳn: điều gì xảy ra khi MỘT hồ sơ phải đi qua NĂM hệ thống khác nhau, do BỐN vai trò khác nhau xử lý, trước khi thật sự 'xong việc' theo đúng nghĩa nghiệp vụ (tiền về tay khách hàng và được ghi sổ đúng). Với hệ thống bảo hiểm, mỗi bước riêng lẻ có thể hoạt động hoàn hảo khi kiểm thử độc lập — form Tiếp nhận nhận hồ sơ tốt, app Giám định lưu ảnh tốt, màn Duyệt hiển thị đúng — nhưng khi ghép lại thành một luồng thật, dữ liệu có thể bị mất giữa hai module, trạng thái có thể 'treo' vì không ai chịu trách nhiệm bàn giao tiếp theo, và số liệu cuối cùng có thể lệch nhau giữa nơi tiền được chi và nơi tiền được ghi sổ. Chúng ta sẽ học qua ClaimFlow: theo dõi trọn vẹn một hồ sơ bồi thường xe từ lúc mở tới lúc đóng.

2. Điểm bàn giao (handoff) & dữ liệu chảy xuyên hệ thống

Trái tim của kiểm thử luồng nghiệp vụ đầu-cuối không nằm ở bên trong một module, mà nằm ở KHOẢNG GIỮA hai module — nơi gọi là điểm bàn giao (handoff point). Tại mỗi điểm bàn giao, một module 'nói xong' phần việc của mình và module kế tiếp phải 'nghe đúng' để tiếp tục. Với luồng bồi thường ClaimFlow, có năm điểm bàn giao chính: Tiếp nhận gửi hồ sơ và ảnh hiện trường cho Giám định; Giám định gửi biên bản và mức đề xuất cho Duyệt; Duyệt gửi số tiền phê duyệt và thông tin thụ hưởng cho Chi trả; Chi trả gửi mã giao dịch và số tiền đã chi thực tế cho Kế toán; và cuối cùng Kế toán đối soát ngược lại với Duyệt để xác nhận số liệu khớp.

Một sai lầm phổ biến khi kiểm thử luồng phức tạp là chỉ kiểm tra CHIỀU GỬI — 'module A có gửi request đi không' — mà quên kiểm tra CHIỀU NHẬN — 'module B có nhận đúng, đủ, và xác nhận lại đúng cách không'. Trong thực tế, phần lớn lỗi luồng nghiêm trọng không nằm ở việc module A 'quên gửi', mà nằm ở việc module B nhận dữ liệu nhưng ÁNH XẠ SAI trường, bỏ sót trường tùy chọn tưởng không quan trọng, hoặc không xác nhận lại cho module A biết là đã nhận thành công — khiến module A tưởng luồng vẫn đang chờ trong khi module B đã âm thầm xử lý xong (hoặc ngược lại, tưởng đã xong nhưng thực ra chưa nhận được gì).

3. Vì sao kiểm thử luồng E2E khó hơn và quan trọng hơn kiểm thử từng module

Kiểm thử từng module riêng lẻ có một lợi thế lớn: dễ kiểm soát dữ liệu đầu vào, dễ đoán kết quả đầu ra, dễ tự động hoá. Nhưng chính vì mỗi module được test tách rời, đội phát triển thường DÙNG DỮ LIỆU GIẢ LẬP (mock) cho các module còn lại — nghĩa là ca kiểm thử pass không chứng minh được gì về việc các module THẬT có 'nói chuyện' đúng với nhau hay không. Với một hệ thống bồi thường bảo hiểm, nơi năm hệ thống khác nhau (có thể do các đội khác nhau, thậm chí nhà cung cấp khác nhau phát triển) phải phối hợp cho MỘT hồ sơ, khoảng trống giữa 'từng module pass riêng lẻ' và 'luồng thật chạy đúng' chính là nơi phần lớn sự cố production xảy ra.

Ngoài ra, luồng nghiệp vụ E2E còn đặc biệt khó vì nó kéo dài qua THỜI GIAN — không phải một request-response tức thì mà có thể mất vài giờ tới vài ngày để một hồ sơ đi từ Tiếp nhận tới Kế toán, với nhiều bước có sự tham gia của CON NGƯỜI (giám định viên đi hiện trường, người duyệt xem xét hồ sơ). Trong khoảng thời gian đó, hồ sơ có thể ở trạng thái 'chờ' rất lâu mà không ai để ý, hệ thống có thể bị bảo trì giữa chừng, hoặc một trong các hệ thống tham gia có thể tạm thời không khả dụng — những kịch bản mà kiểm thử chức năng thông thường (chạy nhanh, trong một phiên) không bao giờ mô phỏng được.

Cuối cùng, hậu quả của lỗi luồng E2E trong ngành bảo hiểm không chỉ là 'trải nghiệm xấu' mà có thể là hậu quả pháp lý và tài chính trực tiếp: hồ sơ treo quá lâu vi phạm cam kết SLA với khách hàng và cơ quan quản lý, chi trả sai số tiền là tổn thất tài chính thật, còn dữ liệu lệch giữa Chi trả và Kế toán có thể dẫn tới báo cáo tài chính sai lệch — một vấn đề nghiêm trọng khi bị kiểm toán. Đây là lý do kiểm thử luồng E2E cần được coi là một hạng mục kiểm thử ĐỘC LẬP, có kế hoạch riêng, không thể chỉ 'suy ra' từ việc từng module đã pass.

4. Chuẩn bị: quy trình & kỹ thuật thiết kế ca kiểm thử E2E

Trước khi viết bất kỳ ca kiểm thử nào, tester E2E cần một bức tranh THẬT về luồng — không phải luồng lý tưởng trong tài liệu đặc tả, mà là luồng thực tế bao gồm cả những đường lỗi mà tài liệu thường bỏ sót. Quy trình dưới đây giúp bạn đi từ sơ đồ luồng tới bộ ca kiểm thử theo nhánh có hệ thống.

▶ Bước 1: Vẽ sơ đồ luồng thật (không phải luồng lý tưởng): liệt kê từng module/hệ thống/vai trò tham gia và đánh số thứ tự các điểm bàn giao.

▶ Bước 2: Với mỗi điểm bàn giao, xác định: dữ liệu gửi đi, dữ liệu/xác nhận nhận về, và SLA thời gian tối đa cho phép.