Kiểm thử dựa trên rủi ro (Risk-Based Testing) cho hệ thống bảo hiểm: ma trận, phân bổ công sức, chọn ca ưu tiên (có trắc nghiệm)

1. Tóm tắt nhanh & màn hình bạn sẽ test

Ở dự án bảo hiểm, danh sách tính năng luôn dài hơn thời gian bạn có. Câu hỏi không phải là 'test được bao nhiêu' mà là 'test cái gì trước để nếu hết giờ, thiệt hại vẫn ở mức chấp nhận được'. Kiểm thử dựa trên rủi ro trả lời chính câu hỏi đó bằng một công thức rất đơn giản nhưng cực kỳ hiệu quả: Rủi ro = Khả năng xảy ra sự cố × Ảnh hưởng nếu sự cố đó xảy ra. Bài này đưa bạn vào hệ thống tính phí & bồi thường bảo hiểm xe cơ giới AnBinhCore của công ty AnBinh, nơi một lỗi công thức tính tiền có thể gây thiệt hại tài chính thật.

2. Rủi ro = Khả năng × Ảnh hưởng: định nghĩa & ma trận rủi ro

Hai trục làm nên mọi quyết định trong RBT là KHẢ NĂNG (likelihood) — xác suất một sự cố xảy ra, thường ước lượng theo độ phức tạp code, tần suất thay đổi, lịch sử lỗi; và ẢNH HƯỞNG (impact) — mức độ thiệt hại nếu sự cố đó thật sự xảy ra, thường ước lượng theo tiền, số khách hàng bị ảnh hưởng, và rủi ro tuân thủ. Nhân hai trục này (thang 1–5) ta có điểm rủi ro từ 1 đến 25.

Điểm số không phải để trang trí báo cáo — nó là căn cứ để RA QUYẾT ĐỊNH: vùng ĐỎ (thường ≥15) là điều kiện bắt buộc phải kiểm kỹ trước khi release, không thương lượng; vùng VÀNG (6–14) cần cân đối giữa chi phí và lợi ích; vùng XANH (≤5) chỉ cần kiểm tra nhanh hoặc chấp nhận rủi ro còn lại (residual risk) mà không kiểm thêm. Cách phân vùng này biến một cuộc tranh luận cảm tính 'test cái này trước hay cái kia trước' thành một con số có thể so sánh khách quan.

3. Vì sao RBT là bắt buộc ở dự án bảo hiểm

Hệ thống bảo hiểm chạm vào ba thứ nhạy cảm cùng lúc: TIỀN (phí bảo hiểm thu vào, tiền bồi thường chi ra), TUÂN THỦ (quy định của cơ quan giám sát bảo hiểm về khả năng thanh toán, minh bạch tính phí, chống gian lận), và UY TÍN (khách hàng mất niềm tin ngay khi biết công ty tính sai tiền của họ). Với ba yếu tố này, kiểm thử dàn trải đều cho mọi màn hình — kể cả những màn hình rủi ro thấp như trang danh sách — là lãng phí thời gian quý giá lẽ ra nên dồn cho công thức tính phí và quy tắc duyệt bồi thường.

Thêm vào đó, tài chính bảo hiểm vận hành theo hiệu ứng nhân bản: một lỗi công thức không chỉ ảnh hưởng một khách hàng mà lặp lại trên hàng nghìn hồ sơ được tính bằng cùng công thức đó, trước khi ai đó phát hiện ra. RBT buộc đội kiểm thử phải trả lời rõ ràng câu hỏi 'nếu chỉ có 20% thời gian, ta bảo vệ 80% giá trị bằng cách nào' — và câu trả lời gần như luôn là: bảo vệ những nơi tiền chảy qua trước tiên.

Vì thế, một tester biết dựng và vận dụng ma trận rủi ro thành thạo sẽ được giao những phần quan trọng nhất của hệ thống, và có tiếng nói đáng tin cậy khi tranh luận về việc có nên release đúng hạn hay lùi lại để kiểm thêm.

4. Chuẩn bị: nhận diện rủi ro trên hệ thống AnBinhCore

Trước khi có ma trận, bạn cần một danh sách rủi ro thô — liệt kê mọi thứ có thể sai, chưa cần chấm điểm vội. Nguồn tốt nhất là tài liệu nghiệp vụ, lịch sử lỗi sprint trước, và phỏng vấn nhanh BA/PO về những vùng họ lo nhất.

▶ Bước 1: Liệt kê mọi tính năng/luồng của module cần test (báo giá phí, xử lý bồi thường, đồng bộ tái bảo hiểm...), không lọc trước.

▶ Bước 2: Với mỗi tính năng, ước lượng KHẢ NĂNG lỗi (1–5) dựa trên độ phức tạp công thức, tần suất thay đổi gần đây, và lịch sử lỗi.

▶ Bước 3: Với mỗi tính năng, ước lượng ẢNH HƯỞNG (1–5) dựa trên số tiền liên quan, số khách hàng bị ảnh hưởng, và rủi ro tuân thủ.