ユーザー受入テストのうちの1つ

他システム連携テスト（外部連携テスト）は、ユーザー受入テスト（UAT）の4種類のうちの1つです。
いずれも、ベンダーとは異なる観点でのテストであり、ベンダーがテストしたからOKとはなりません。ユーザー側で責任をもって行う必要があります。

（要求機能テスト）

・各機能単位で確認するテスト
・現場視点でバリエーションを確認する
　　例1：請求書レイアウトパターン網羅
　　例2：各画面項目の過不足
 

（システム間連携テスト）

・新システムと外部システムの連携部分を確認する
・ベンダーは外部システムは直接操作できないので、ユーザーにて外部システムを直接操作し、確認する
 

（シナリオテスト）

・業務の流れを上から下まで、取引を「通し」で確認する
・実際の取引を再現し、業務が回るかを確認する
 

（現新比較テスト）

・現行と新でシステム出力結果が一致するかを確認する
・主に全件データで集計結果が一致するかを確認する
・移行データ（マスタ・トランザクション）が正しいか確認する

（※ 画像をクリックすると、大きな画像が表示されます）

 

他システム連携テストの位置づけ

他システム連携テストは、実際に新システムと周辺システムを接続して、データが連携されるかを確認するテストです。

ベンダーは、周辺システムを実際に動かすことはできません。そのため、ベンダーは入出力の「ファイル」までしか検証できません。つまり、実際に周辺システムを動かした連携テストは、ユーザー側でしかできないテストといえます。

 

他システム連携テスト項目書のイメージ（簡易版）

他システム連携の細かい機能検証は、ベンダー側で実施しています。

そのため、ユーザー側では細かな確認は省略し、「疎通確認」という位置づけで行います。

従って、テスト項目はシンプルとなります。

（※ 画像をクリックすると、大きな画像が表示されます）

No.1のファイル取り込みで、エラーが発生しなければ「だいたいOK」です。

ただし、何かあった場合に調査できる手段は確立しておきたいので、No.2のログ出力は確認しましょう。

No.3のデータマッピングは、項目単位に正しくセットされているかを確認するものです。ボリュームが多いため、状況によってはサンプリングチェックでもよいと思います。

 

他システム連携テスト項目書のイメージ（詳細版）

しかしながら、簡易版のテストで許されない状況もあるかと思います。
・ベンダーの品質が信用できない
・環境が特殊でベンダーではテストができない
・予算の関係で、他システム連携は内製した

特に最後の「内製」は、近年増えているように感じます。RPAなど「ノーコードツール」で開発できるため、情シスが対応しやすくなった背景があります。

このような場合は、詳細なテスト項目を作っていきます。

（※ 画像をクリックすると、大きな画像が表示されます）

他システム連携テストにおける代表的な確認項目を並べましたが、必要に応じて追加・省略などアレンジしてみてください！

 

（↓他システム連携の考え方については、以下を参照してください↓）
他システム連携テスト（外部連携テスト）は誰が行うべきか？

 
 

（↓関連記事↓）
受入テスト（UAT）計画書の作り方（サンプル画像付き）
要求機能テスト項目書の作り方（サンプル画像付き）
シナリオテスト項目書の作り方（サンプル画像付き）
リリース判定／本稼働判定の作り方（サンプル画像付き）

 
 

＊＊＊＊＊
 
 
※ 弊社で公開しているサンプルについては、基本的に画像のみの提供とさせていただいております。ファイルデータのダウンロードを可能とすると、内容の吟味をせずにそのまま流用し、トラブルに発展する可能性があるためです。画像データから文字起こしを行う過程で、それぞれのプロジェクトの状況に合わせてアレンジしていただければ幸いです。