免責事由や支払限度額の境界値で支払可否の判定が反転する
免責事由の判定は、該当するかしないかの境界値で支払可否が反転します。改修時に境界値の検証を省略すると、支払うべき案件が不払いとなります。
GENZ, Inc.
保険金査定の現場に
保険査定システムの
保険金査定の現場に
保険査定システムの支払判定を第三者視点で検証します
改修で問われるのは、どこまで検証すればリリースしてよいかです。GENZは支払可否と支払額のロジックを読み解き、検証範囲と優先順位を根拠とともに示します。
支援事例
支援実績5,000件以上
保険査定システムでよくある不具合
保険金査定システムは、契約内容と査定基準の照合で支払可否と支払額を決めるため、不具合は契約者への支払に直接及びます。改修・更改のたびに検証すべき箇所は、判定ロジックとデータ反映の境界に集まります。
免責事由や
計算順序の誤りで支払額の内訳が約款の定めと一致しない
支払限度額・免責金額・割増率の計算順序が約款の定めと異なると、支払額の内訳が一致しません。稼働後は過去分の再計算と追加支払が生じます。
OCRで抽出した請求書の項目が確定値へ正しく反映されない
OCRの抽出値が誤読や桁落ちのまま確定値へ反映されると、査定ロジックが誤った入力で判定します。個人情報の制約でテストデータを用意できません。
契約異動の反映前に受け付けた請求が、古い契約内容で査定される
契約異動の反映と請求受付の順序に不整合があると、古い契約内容で査定されます。異動処理との連携を確認せずリリースすると支払誤りが表面化します。
自動査定の振り分け条件に不整合があり、手作業の対応が滞留する
自動査定で判定できない案件の振り分け条件に不整合があると、手作業での対応が査定部門へ滞留します。原因の切り分けができず調査が長引きます。
残存した不具合により生じる問題
保険金査定システムに不具合が残ったまま稼働すると、支払額の誤り・支払の遅延・説明根拠の喪失という形で、査定部門と契約者へ直接影響が及びます。
静的テスト（レビュー）でおさえるべき観点
査定ロジックの期待値は、動的テストの実行前に設計書・約款・運用手順の照合で固めることができます。文書の不整合を先に検出すれば、期待値を断定できない項目をテスト項目書へ持ち込まずに済みます。
査定基準の正本を確定しないままテスト設計に入ると、期待値を断定できない項目が残り、受け入れテストの都度の口頭確認が発生します。確認が追いつかない項目は検証範囲から外される判断につながるおそれがあります。
査定基準の正本と設計書の判定条件を照合する
査定基準の正本がコードと運用手順に分散していると、設計書上の判定条件がどの基準に基づくか判別できません。要件定義の段階で正本と判定条件を照合し、支払可否と支払額の期待値を文書として残します。
確認する資料
- 査定基準書
- 基本設計書
- 運用手順書
改定内容と改修範囲の対応漏れは、施行日に間に合わせるために検証範囲を削る判断を生み、削った根拠を説明できないままリリース判断の材料を提出することになります。
約款・支払基準の改定内容と改修範囲の対応を照合する
約款改定や支払基準の変更では、改定された条項と改修対象の機能の対応関係が漏れやすくなります。施行日が固定された改修では特に、改定内容と改修範囲を照合し、対応漏れを残さずテスト設計へ進みます。
確認する資料
- 約款
- 改定資料
- 要件定義書
マスタ構造と改訂単位の不整合は、影響範囲が小さいという判断で回帰テストの範囲を最小化した場合に、既存の査定ロジックのデグレードを検知できない状態を生みます。
DB設計書のマスタ構造と査定基準の改訂単位を照合する
査定基準マスタの改訂が運用作業で行われる場合、DB設計書のマスタ構造と改訂単位が一致していないと、反映漏れや既存ロジックへの影響を検知できません。マスタの項目単位と改訂の単位を照合します。
確認する資料
- DB設計書
- マスタ定義書
- 改訂手順書
連携先とのデータ項目の不整合は、支払額の算定結果の差異として稼働後に表面化し、原因がデータ起因か査定ロジック起因か切り分けられず、調査が長引くおそれがあります。
API定義と連携先システムのデータ項目・桁・書式を照合する
契約管理システムや会計・出金システムとの連携では、データ項目の定義や桁、書式の不整合が連携先で差異として表面化します。API定義と連携先の仕様を照合し、計算順序の正本の所在も確認します。
確認する資料
- API定義書
- 連携仕様書
- 項目対応表
例外処理の振り分け基準が運用手順にないと、判定できない案件が手作業での対応となって査定部門へ滞留し、滞留が表面化してから原因調査が始まる状態になります。
例外処理とエラー発生パターンの記述と運用手順を照合する
自動査定で判定できない案件を手作業へ振り分ける基準が運用手順に記述されていないと、滞留の原因を切り分けられません。例外処理とエラー発生パターンの記述と運用手順の振り分け基準を照合します。
確認する資料
- 詳細設計書
- 運用手順書
- エラーコード一覧
- 障害対応手順書
動的テストの設計・実行のポイント
査定ロジックの改修では、判定条件から業務シナリオ全体まで工程ごとに対象を分けて設計し、各工程の期待値を文書として残します。
STEP 01
ユニットテスト期待値が確定しない項目は保留にして進めません
どう確かめるか
ユニットテストで支払可否の判定条件を境界値分析と同値分割で確かめる
支払可否と支払額を決める判定条件を、免責事由や支払限度額の境界値と同値分割で項目化します。査定基準の正本と突き合わせ、条件付きの回答が残る項目は業務主管へ確認して期待値を確定します。
- 01支払可否の判定条件を査定基準と突き合わせて一覧化する
- 02免責事由と支払限度額の境界値を項目化する
- 03条件付きの回答が残る項目の期待値を業務主管と確定する
OUTPUT判定条件の期待値一覧
STEP 02
統合テスト計算順序の正本の所在を先に確認します
どう確かめるか
統合テストで契約管理・支払会計との境界をまたぐデータの受け渡しを確かめる
契約管理システムと支払会計側で支払額の計算順序の正本が分かれる境界で、データの受け渡しと計算結果の一致を確かめます。境界値や例外処理とエラー発生パターンを重点的に検証します。
- 01契約管理・支払会計との間で支払額の計算順序の正本を確認する
- 02境界をまたぐデータの受け渡しで計算結果の一致を確かめる
- 03例外処理とエラー発生パターンを意図的に発生させて検証する
OUTPUT境界またぎの受け渡し結果
STEP 03
システムテスト手作業への振り分け基準も検証対象に含めます
どう確かめるか
システムテストで請求受付から支払通知までの業務シナリオを通して確かめる
請求受付から契約照合、査定、支払通知までの業務シナリオを通して実行します。自動査定で判定できない案件が手作業での対応へ振り分けられる経路も含め、判定の不一致を検知できる状態にします。
- 01請求受付から支払通知までの業務シナリオを通して実行する
- 02自動査定で判定できない案件の振り分け経路を検証する
- 03非定型の添付資料を入力とする抽出結果の確認を行なう
OUTPUT業務シナリオの通し結果
STEP 04
受け入れテスト・回帰テスト影響範囲が小さい改修でも回帰範囲の根拠を残します
どう確かめるか
受け入れテストと回帰テストで改定後の査定結果と既存商品の挙動を確かめる
改定後の査定結果が従前と一致するかを確認し、削った検証項目とその根拠を記録します。基盤更改やパッチ適用でも既存の査定ロジックへ回帰テストを行い、デグレードを検知できる範囲を維持します。
- 01改定後の査定結果が従前と一致するかを確認する
- 02削った検証項目と根拠をリリース判断の材料として記録する
- 03既存の査定ロジックのデグレードを回帰テストで検知する
OUTPUT改定前後の差異の確認記録
GENZが代行する保険査定システムのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 査定基準を文書化し、テスト項目書の期待値へ反映します。
- 検証範囲と優先順位を第三者の視点で整理し、根拠を示します。
- 帳票をマスキングし、記載揺れのテストデータを用意します。
- 自動判定の境界値を設計し、手作業への振り分けを検証します。
査定ロジックから検証範囲を決める
GENZは、保険金査定システムの支払可否と支払額の判断ロジックを読み解き、テスト設計から実行までを担います。発注側・ベンダーのいずれにも属さない第三者の視点で、検証範囲と優先順位を根拠とともに示します。
査定基準と業務フローからテスト設計を起こす
査定部門が持つ査定基準と支払可否ルールを確認し、提出書類の照合から支払額の計算まで、業務フローに沿ったテスト設計を起こします。
連携先をまたぐ検証範囲と優先順位
契約管理システムや保険金支払システムをまたぐ範囲を整理し、限られた期間でどこまで検証すれば足りるかを根拠とともに示します。
既存のベンダー体制に合わせて入る
品質保証部門の配置は案件ごとに異なります。GENZは既存の体制を置き換えず、ベンダー側テストやスプリントに合わせて入ります。
検証の範囲と結果を報告書に残す
不具合の有無だけでなく、どの範囲をどう検証したかの証跡を報告書に残します。リリース判断や稟議の資料として後から参照できる形で納めます。
ご相談から納品までの流れ
保険金査定システムの検証は次の工程で進めます。各工程の成果物を共有し、既存のベンダーと役割を分けます。
改修内容と検証したい範囲のヒアリング
改修の対象と査定基準の変更箇所を確認し、テスト観点の案へ整理します。
テスト設計と見積もりのご提示
整理した観点からテスト設計し、検証範囲・期間・工数を見積もりで示します。
テストの実施と進捗・不具合票の共有
テストを実施し、進捗と不具合票を共有します。報告先は事前に取り決めます。
報告書の納品と修正後の再確認
検証の範囲と結果を報告書にまとめて納品し、修正後の該当箇所を再確認します。
保険査定システムのテスト外注をご検討の企業様へ
保険査定システムのテストは、検証の範囲と優先順位からご相談ください
ご相談では、査定ロジックを踏まえたテスト範囲の整理と優先順位、必要工数の考え方をお示しします。回帰テストなど関連テストの要否も含め、稟議の材料として使える形でご提示します。