差分取り込みの判定誤りで同一レコードが二重に登録される
差分取り込みの判定が提供元の更新日時と一致しないと、同一レコードが二重に登録されます。処理は正常終了するため、ジョブ監視では検知されません。
GENZ, Inc.
設計書照合から受け入れまで
DWHの
設計書照合から受け入れまで
DWHの変換・集計ロジックを第三者視点で検証します
抽出・変換・格納・マート生成・レポート提供まで、工程ごとに誰が何を確かめたかを示せる形で、実装者から独立した検証を行います。
支援事例
支援実績5,000件以上
DWHでよくある不具合
DWHの不具合は、処理の成否の監視だけでは検知できません。抽出からマート生成、レポート提供までの各工程で、変換規則や適用時点の不一致が集計値の差異として表面化します。ここでは工程ごとに整理します。
差分
データ型と桁数の変換で金額の下位桁が欠落する
文字コードや桁数の変換定義が仕様と一致しないと、金額の下位桁が欠落したままDWHへ格納されます。マート集計で月次合計の不整合となります。
マスタの適用時点の相違で部門別集計が基幹システムと一致しない
マスタの適用開始日が基幹システムとDWHで異なると、同じ取引が別の部門へ集計されます。部門別の集計値が一致せず、利用者の指摘で表面化します。
ジョブの異常終了と再実行で対象期間のデータが重複して残る
ジョブの異常終了後に再実行すると、対象期間のデータが重複して残ります。投入済みの期間の削除を手順に定めていない場合に起きます。
締め時刻とタイムゾーンの扱いの違いで月末の取引が翌月に計上される
提供元システムとDWHで締め時刻やタイムゾーンの扱いが異なると、月末の取引が翌月に計上されます。月次の集計値が原票と一致しません。
残存した不具合により生じる問題
DWHに残存した不具合は、処理の現場に留まらず経営の判断場面へ波及します。集計値の不整合を放置した場合に生じる代表的な問題を整理します。
静的テスト（レビュー）でおさえるべき観点
抽出から提供までの不整合の多くは、実装前の段階で設計書と定義書の不一致として検出できます。実装者の自己点検に留めず、文書どうしの照合として記録に残すことが、後工程の検証範囲を説明する根拠になります。
提供元の仕様変更が設計書へ反映されないまま運用が続くと、正常終了したジョブが欠落した値をDWHへ格納し続けるおそれがあります。
提供元仕様と設計書のデータ型を照合する
取り込み元のテーブル仕様とDWH側の設計書で、データ型と桁数とNULLの扱いを照合します。型の不一致はジョブが正常終了したまま値の欠落として残るため、提供元の仕様変更のたびに差分を確認します。
確認する資料
- テーブル仕様書
- データ型定義書
- DWH設計書
変換規則の解釈違いが実装者の自己点検で見送られると、マッピング定義どおりに動作しても業務の期待値と合わないデータが残ります。
ETL設計書とマッピング定義の変換規則を照合する
ETL設計書の変換規則とマッピング定義を一項目ずつ照合し、解釈の相違を実装前に検出します。実装したベンダーがテスト仕様も作る体制では、同じ解釈違いがそのままテストを通過してしまいます。
確認する資料
- ETL設計書
- マッピング定義書
- 変換規則一覧
計算順序の相違が修正されないままリリースされると、経営会議の資料で部門間の数値が一致しない状態が表面化します。
集計ロジックの計算順序と業務ルールの定義を照合する
集計ロジックの計算順序と、締め日や部門所属など業務ルールの定義を照合します。集計の前段で何を除外し何を含めるかが文書上で一致していないと、レポート間で数値が一致しない状態が残ります。
確認する資料
- 集計ロジック定義書
- 業務ルール定義書
- マート定義書
境界値と例外処理がテスト項目書から抜けたまま受け入れテストが終了すると、デグレードが利用者の指摘で判明します。
テスト項目書と境界値の洗い出し結果を照合する
テスト項目書が、境界値と例外処理とエラー発生パターンの洗い出し結果を網羅しているかを照合します。件数と合計値の概観確認に留まる項目書では、端数や欠損を含む不整合を検出できません。
確認する資料
- テスト項目書
- 境界値一覧
- 例外処理一覧
再実行の運用と依存関係の定義が一致しないまま月次締めを迎えると、原因調査が提供元とベンダーに分かれて長期化します。
ジョブの依存関係の定義と締め時刻・再実行の運用手順を照合する
ジョブの依存関係の定義と、締め時刻・再実行の運用手順を照合します。再実行の順序が定義と異なると途中のマートが古い値のまま確定し、差異の切り分けに手作業での対応が発生します。
確認する資料
- ジョブフロー図
- ジョブ定義書
- 運用手順書
- 締め時刻一覧
動的テストの設計・実行のポイント
DWHのテストは、変換処理・ジョブ連携・表示値の突合・業務シナリオに分けて設計し、検証範囲を工程名で説明できる状態にします。
STEP 01
ユニットテスト変換処理単位で実施
どう確かめるか
ユニットテストで変換処理ごとの境界値と例外処理とエラー発生パターンを確認する
ETLの変換処理ごとに、境界値と例外処理とエラー発生パターンを確認します。マッピング定義と計算順序の照合をこの段で記録として残すことで、実装者の自己点検に留まらない根拠を作ります。
- 01マッピング定義と計算順序を設計書と照合する
- 02境界値の入出力を変換処理ごとに確認する
- 03例外処理とエラー発生パターンを確認する
OUTPUTマッピング定義の照合記録
STEP 02
統合テストジョブを通しで実施
どう確かめるか
統合テストで抽出から格納までのジョブ連携と再実行時のデータ整合を確認する
抽出から格納までのジョブ連携を通しで検証し、異常終了後の再実行でデータの整合が保たれるかを確認します。再実行の運用ルールと依存関係の定義が一致しないと、重複や欠落が格納後まで残ります。
- 01抽出から格納までのジョブ連携を検証する
- 02異常終了後の再実行で重複と欠落を確認する
- 03マスタ更新の反映タイミングを確認する
OUTPUTジョブ連携の確認結果
STEP 03
システムテスト表示値と原票で突合
どう確かめるか
システムテストでBIツールの表示値と基幹システムの原票を突合する
BIツールの表示値と基幹システムの原票を突合し、集計条件とマスタの反映を確認します。監視が処理の成否だけでは値の不整合を検知できないため、利用者の指摘前にここで検出します。
- 01BIツールの表示値と原票を突合する
- 02集計条件とマート生成ロジックを確認する
- 03月次締めの集計値を過去実績と照合する
OUTPUT表示値と原票の突合表
STEP 04
受け入れテストと回帰テスト業務シナリオと影響範囲で実施
どう確かめるか
受け入れテストと回帰テストで業務シナリオと改修の影響範囲を確認する
受け入れテストでは業務シナリオに沿って主要レポートの合否を確認し、改修時は回帰テストの対象を変更箇所と影響レポートの対応関係から決めます。毎回ゼロから範囲を決め直す状態を解消します。
- 01業務シナリオに沿った受け入れテストを実施する
- 02変更箇所と影響レポートの対応関係を整理する
- 03回帰テストの範囲と合否基準を確認する
OUTPUT回帰テストの対象範囲表
GENZが代行するDWHのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 誰がどこまで確かめたかを工程名で示せる記録が残ります
- 境界値と例外処理をリリース前に検証し、不整合を検知できます
- 第三者の視点で変換規則の解釈違いを検出できます
- 集計ロジックとレポートの対応関係が回帰テストの根拠になります
出所から集計まで一貫検証
DWHの検証は、データの出所からBIツールの集計値まで工程ごとに区切る必要があります。GENZは設計書の照合から受け入れテストまでを第三者の視点で担い、どの工程を誰が確かめたかを記録として残します。
設計書を起点にテスト設計する
マッピング定義とテーブル定義を起点に、抽出・変換・格納の各工程のテスト設計を行ないます。実装前に確認すべき観点を整理します。
基幹システムからBIツールまで検証
抽出、ETLの変換、DWHへの格納、マート生成、レポート提供までを検証範囲に含め、ユニットテストから回帰テストまで対応します。
既存の体制に役割を合わせて伴走する
発注側・ベンダー側・独立品質管理部門のどの配置にも合わせ、実装者と検証者を分けて進めます。計画の作成、レビュー、実行の代行を担います。
監査に使える不具合票と報告書を納品
テスト項目書、不具合票、報告書、証跡の整理を納品します。稟議と監査の双方で使える形式でそろえ、リリース判断の材料になります。
ご相談から納品までの流れ
ご相談から納品までは、範囲の確認、設計と見積もり、テスト実施、報告書納品の順で進みます。
ヒアリングで対象と範囲を確認する
検証対象のマートとレポート、ETLの範囲、運用ルールをお聞きします。
テスト設計と見積もりを提示する
テスト設計を行ない、委託範囲と自社に残す工程を分けて見積もりを提示します。
テストを実施し進捗と不具合票を共有する
テストを実施し、進捗と不具合票を共有します。不具合は証跡付きで記録します。
報告書を納品し改修後の再確認を行なう
監査にも使える報告書を納品し、改修箇所は回帰テストで再確認します。
DWH・ETLの検証範囲を整理する無料相談
DWHの検証範囲と優先順位をGENZへご相談ください
ご相談では、抽出から格納・マート生成・レポート提供までの検証範囲の切り分け、対象の優先順位づけ、回帰テストの要否までを、社内の稟議に使える形で整理してお返しします。