はじめに

大規模なシステム移行・フロー刷新のST(システムテスト)を設計する際、「とりあえず一通り動かして確認する」というアプローチでは、テストの抜け漏れや、逆に不要な範囲までテストしてしまう非効率が発生しがちです。

今回、複数システムが絡むデータ連携フローの刷新プロジェクトでSTを設計・運用した経験から、「サイクルごとに目的と対象外を明確にする」という考え方についてまとめます。

前提:何のためのSTか

対象は、旧システムの保守終了に伴い、データ連携フローを新フローに置き換えるプロジェクトでした。データの取込から後続処理、ファイル出力までの一連の流れが、新フローで問題なく動作することを確認するのがSTのゴールです。

このとき最初に決めたのは、「一連の流れ全体を1回のテストで検証しようとしない」 ということでした。複数システムをまたぐ以上、疎通の確認・正常なシナリオの確認・異常時の確認・性能の確認を同じテストの中で一気にやろうとすると、何か問題が起きたときにどの観点の不備なのか切り分けがしづらくなります。

そこで、テストをいくつかのサイクルに分割し、各サイクルで「何を保証するか」と「何を保証しないか(対象外)」を明文化する という進め方を取りました。

サイクル設計の全体像

大枠として、以下のような段階に分けました。

0. 疎通テスト/環境接続確認

検証目的:認証情報・アクセス権限の妥当性、システム間の通信経路が確立されていることの確認。あくまで「本格的なテストに入れる状態か」を見るための事前チェック
対象外:転送されるデータの中身の正当性(フォーマットや業務ロジック)。ここは次のサイクルで見る

最初から「ここではデータの中身は見ない」と明言しておくことで、疎通確認の作業がデータ検証にまで広がって工数が膨らむのを防げます。

サイクル1:正常系テスト

検証目的:規定のシナリオに沿って、一連の処理が遅滞なく完遂すること。システム間連携を含めたデータの整合性
対象外:未定義のイレギュラーパターンへの対応、本番環境特有の設定に起因する事象、高負荷条件下でのパフォーマンス

正常系サイクルでは「決められた通りに動かして、決められた通りの結果になるか」だけを見る、と割り切ります。異常系や性能は後続のサイクルに任せることで、このサイクルの合否判定がシンプルになります。

サイクル2:異常系テスト

検証目的:想定される例外パターンに対して、定義されたエラーハンドリングが正しく機能すること。エラー通知の内容・タイミングの妥当性。異常発生時にもシステムが制御不能な状態に陥らないこと
対象外:予期しない複合的な障害パターンへの網羅的な対応、本番稼働時のみ発生しうる多重障害

異常系はパターンを無限に広げようとすると際限がなくなるため、「想定される例外パターン」という形であらかじめ範囲を区切っておくことが重要でした。

サイクル3:性能テスト

検証目的:本番相当のデータ量を用いて、バッチ全体が運用上許容可能な時間内に完了すること。一定の負荷条件下でのレスポンスタイムやスループットが基準を満たすこと
対象外:検証環境と本番環境の差異による性能数値の完全な再現性、他システムとの突発的な競合による影響

性能テストは環境差の影響を受けやすいため、「検証環境での数値がそのまま本番を保証するものではない」という前提を明記しておくことで、後々の期待値のズレを防げます。

「対象外」を明記することの効果

このST設計で特に効果を感じたのは、各サイクルの検証目的だけでなく 「対象外」を必ずセットで書く という点でした。

対象外を明示しないと、

テスト実施者ごとに「どこまで確認すべきか」の解釈がぶれる
あるサイクルで見つかった問題が、実は別のサイクルで検証すべき範囲だった、という手戻りが発生する
ステークホルダーから「なぜこのケースを確認していないのか」という後出しの指摘を受けやすくなる

といったことが起きやすくなります。事前に「このサイクルではここまでしか見ません」と合意しておくことで、各サイクルの守備範囲がクリアになり、複数チームが関わる体制でも役割分担がしやすくなりました。

複数チームが関わる体制での役割分担

このプロジェクトでは、複数のシステム・複数のチームが関わっていたため、役割分担も以下のように整理しました。

全体の検証計画(各サイクルの目的・対象外の定義)の策定と、チーム間の進捗調整は、データ活用側のチームが担当
各システム個別の詳細なテストケースの検討・実施・エビデンス採取は、各システムを担当するチームがそれぞれ担当
サイクル終了ごとの結果の相互確認、課題の早期共有は共通の役割とする

全体設計を握るチームと、個別実装を持つチームの役割を分けることで、「全体としての一貫性」と「各システムの専門性」を両立させることを意識しました。

まとめ

複数システムが絡むSTを設計する際は、

一連の流れを一度に検証しようとせず、疎通・正常系・異常系・性能といった観点でサイクルを分割する
各サイクルで「検証目的」だけでなく「対象外」も明文化する
複数チームが関わる場合は、全体設計と個別実装の役割を分けて整理する

という進め方が、テストの抜け漏れ防止とチーム間の認識合わせの両方に効いてくると感じました。