はじめに
システム間連携のSTでは、「連携される全ファイルが正しく後続処理まで届いているか」を確認する場面があります。ファイルの数が数十〜百件規模になると、1件ずつ手作業で中身を確認するのは現実的ではありません。
今回、インターフェースファイルの数が多い状況でSTを行った際に、どう検証範囲を絞り込みつつ品質を担保したかをまとめます。
課題:ファイル数が多すぎて全件は確認できない
対象のテストでは、正常パターン・異常パターン・大容量パターンなど、複数の観点をカバーする形で多数のインターフェースファイルが用意されていました。
これを1件ずつ開いて中身を目視確認していては工数的に破綻します。かといって、確認する件数を絞りすぎると、特定のパターンに固有の不具合を見逃すリスクが上がります。
アプローチ:パターン分類してからサンプリングする
そこで取ったアプローチが、ファイルを無作為に抽出するのではなく、まずパターンごとに分類し、各パターンから代表的なファイルをサンプリングするという進め方です。
具体的には、以下のような分類軸を意識しました。
- 正常系のファイル(想定通りのフォーマット・データ量)
- 異常系のファイル(欠損、フォーマット崩れ、想定外の値を含むもの)
- 大容量・境界値のファイル(サイズが大きい、件数が極端に多い/少ないもの)
全件を均等にチェックするのではなく、「このパターンの代表として、このファイルを見ればこのパターン全体の挙動が推測できる」という単位でサンプリングすることで、確認工数を現実的な範囲に抑えつつ、パターンの網羅性を落とさないようにしました。
検証方法:行数・件数の一致確認
個々のファイルについて「正常に下流に届いているか」を確認する際の基準としたのが、送信元と連携先での行数・件数が一致しているかという観点でした。
中身の値まで1件ずつ突き合わせるのではなく、まず件数レベルで欠落や重複が発生していないかを確認することで、
- ファイルの一部が処理されずに欠落している
- リトライなどにより重複して取り込まれている
といった、連携フローとして致命的な問題を効率よく検知できます。件数さえ一致していれば、中身の詳細な正当性は別の観点(業務ロジックのテストなど)に任せる、という役割分担です。
この進め方のメリットと注意点
パターン分類 + サンプリング + 件数一致確認、という組み合わせのメリットは、ファイル数が多い状況でも現実的な工数で一定の網羅性を確保できる点です。
一方で注意点として、
- パターン分類自体が漏れていると、そのパターンに固有の不具合を検知できない
- 件数一致確認はあくまで「欠落・重複がないか」を見るものであり、中身の正当性(値そのものが正しいか)までは保証しない
という限界があります。そのため、サンプリングによる件数確認はあくまでST全体の中の一つの観点であり、他のサイクル(正常系の業務ロジック確認など)と組み合わせて初めて全体の品質を担保できる、という位置づけで運用しました。
補足:全量確認とサンプリング確認の使い分け
なお、サンプリング確認は、すべての確認を省略するためのものではありません。
ファイルの到達有無、出力件数、取込件数の一致といった機械的に確認できる観点については、可能な限り全量で確認することが望ましいです。これにより、特定のファイルだけが未連携になっている、または一部のファイルだけ件数不一致が発生している、といった問題を検知できます。
一方で、各ファイルの中身を目視で確認したり、業務ロジック上の妥当性まで詳細に確認したりする作業を全件に対して行うのは、工数面で現実的ではありません。そのため、詳細確認についてはパターン分類を行ったうえで、各パターンから代表ファイルをサンプリングして確認する形としました。
つまり、全量確認とサンプリング確認はどちらか一方を選ぶものではなく、確認観点ごとに使い分けることが重要だと感じました。
まとめ
大量のファイルを扱うSTでは、全件を同じ精度で確認しようとするのではなく、
- まずファイルをパターンに分類する
- 各パターンから代表ファイルをサンプリングする
- 個々のファイルは、まず件数レベルの一致を確認し、致命的な欠落・重複を検知する
という段階的なアプローチを取ることで、限られた工数の中でも一定の品質担保ができると感じました。