Thực chiến Bảo hiểm: thẩm định & bồi thường theo bảng quyết định (claims)

1. Bối cảnh nghiệp vụ: quy mô, SLA và tuân thủ trong bồi thường bảo hiểm

Một công ty bảo hiểm phi nhân thọ xử lý trung bình mười hai nghìn hồ sơ bồi thường mỗi ngày trên các sản phẩm sức khoẻ, xe cơ giới và du lịch. Mỗi hồ sơ đi qua ba trạm: tiếp nhận (FNOL), thẩm định tự động bằng rule engine, và ra quyết định approve, deny hoặc chuyển thẩm định viên xử lý tay. Sai một quyết định không chỉ là lỗi phần mềm mà là rủi ro tài chính và pháp lý: chi trả nhầm một ca thuộc điều khoản loại trừ làm thất thoát tiền, còn từ chối nhầm một ca hợp lệ khiến khách hàng khiếu nại và cơ quan quản lý vào cuộc.

SLA nghiệp vụ đặt ra: chín mươi phần trăm hồ sơ đơn giản phải có quyết định trong hai giờ, và không hồ sơ nào bị chi trả vượt hạn mức hợp đồng dù chỉ một đồng. Về tuân thủ, mọi quyết định phải để lại vết kiểm toán (audit trail) đầy đủ, và cách tính phí bảo hiểm phải khớp với bảng hệ số actuarial đã được cơ quan quản lý phê duyệt. Đây là lý do vì sao đội QA không thể chỉ kiểm thử bằng cách bấm vài nút trên giao diện: phải kiểm thử chính logic bảng quyết định như một oracle độc lập.

Bài viết này đi theo hướng oracle-first: chúng ta không khẳng định 'màn hình hiện chữ Đã duyệt', mà khẳng định 'với đúng bộ điều kiện này, hệ thống phải ra đúng quyết định này và số tiền chi trả phải bằng đúng giá trị này'. Kỹ thuật chủ đạo là data-driven testing: mã hoá bảng quyết định thành một tệp CSV, mỗi hàng là một ca kiểm thử, rồi tham số hoá để Playwright sinh ra hàng loạt test từ cùng một khung. Nhờ vậy khi phòng nghiệp vụ đổi một luật, ta chỉ sửa dữ liệu chứ không viết lại code test.

2. Kiến trúc hệ thống và ranh giới kiểm thử

Hệ thống gồm bốn thành phần chính. Cổng tiếp nhận nhận hồ sơ từ web, app và đối tác qua API. Dịch vụ hợp đồng cung cấp thông tin hạng gói, thời gian chờ và các điều khoản loại trừ. Rule engine là trái tim: nó nạp bảng quyết định phiên bản hoá và trả về quyết định cùng số tiền đề xuất. Dịch vụ chi trả thực hiện giao dịch kép (double-entry) để đảm bảo tiền không tự sinh hay biến mất. Đội QA phải xác định rõ mỗi lớp kiểm thử phủ phần nào để tránh vừa thiếu vừa trùng lặp.

Ở tầng đơn vị, ta kiểm thử rule engine như một hàm thuần: đầu vào là bối cảnh hồ sơ, đầu ra là quyết định và số tiền — không chạm giao diện, chạy cực nhanh, phủ hết mọi cột của bảng quyết định. Ở tầng API, ta kiểm thử toàn bộ chuỗi từ tiếp nhận đến quyết định, xác nhận audit trail và trạng thái lưu đúng. Ở tầng end-to-end với Playwright, ta chỉ chọn một số kịch bản đại diện quan trọng để chứng minh luồng người dùng thật hoạt động, tránh nhồi mọi tổ hợp vào E2E vì chậm và giòn.

// playwright.config.ts — cấu hình dự án bảo hiểm, tách tầng bằng project.
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  reporter: [['html'], ['junit', { outputFile: 'results/junit.xml' }]],
  use: {
    baseURL: process.env.CLAIMS_BASE_URL ?? 'https://staging.claims.internal',
    trace: 'retain-on-failure-and-retries',
    // v1.60: HAR là công dân hạng nhất trong tracing
    // tracing.startHar()/stopHar() bật ở fixture khi cần.
  },
  projects: [
    { name: 'api',  testMatch: /.*\.api\.spec\.ts/ },
    { name: 'e2e',  testMatch: /.*\.e2e\.spec\.ts/, use: { ...devices['Desktop Chrome'] } },
  ],
});

3. Mô hình dữ liệu và các bất biến làm oracle

Mô hình dữ liệu tối giản gồm bốn thực thể. Hợp đồng có hạng gói, ngày hiệu lực, thời gian chờ theo từng quyền lợi và danh sách điều khoản loại trừ. Hồ sơ bồi thường có loại rủi ro, ngày xảy ra, số tiền yêu cầu và liên kết tới hợp đồng. Quyết định lưu kết quả (approve, deny, manual), số tiền chi trả và lý do. Sổ cái ghi các bút toán chi trả theo nguyên tắc kép. Chính từ mô hình này ta rút ra các bất biến — những mệnh đề luôn đúng bất kể đầu vào — và biến chúng thành oracle của kiểm thử.

• Bất biến 1 — Giới hạn chi trả: payout luôn nhỏ hơn hoặc bằng hạn mức còn lại của quyền lợi; không bao giờ âm.
• Bất biến 2 — Thời gian chờ: hồ sơ có ngày xảy ra trước khi hết thời gian chờ luôn bị deny với lý do WAITING_PERIOD.
• Bất biến 3 — Loại trừ: rủi ro thuộc điều khoản loại trừ luôn deny với lý do EXCLUSION, không phụ thuộc số tiền.
• Bất biến 4 — Bảo toàn tiền: tổng nợ bằng tổng có trong sổ cái sau mỗi chi trả (double-entry cân bằng).
• Bất biến 5 — Phí bảo hiểm: phí tính ra phải bằng tích các hệ số actuarial theo bảng đã duyệt, sai số làm tròn ≤ 1 xu.