外部システムの連携テストはどこまで？代替応答と受け手記録の確かめ方

「連携試験済み」を、送信・返答・受け手記録へ分ける

外部連携テストは、社内の注文を別のシステムへ渡す接点と、その結果を確かめる試験です。「つながった」という一言を、送った情報、相手からの返答、受け手に残る記録へ分けて聞くと、確かめた範囲が見えてきます。

関わる役割は受発注システムのIT発注担当、開発会社、配送先システムの担当です。発注担当は終えたい仕事と判断に必要な証拠を伝え、開発会社は自社側の試験と接続方法を、配送側は使える試験環境や記録の確認方法を説明します。この役割名だけで、実際の担当者や了承が決まるわけではありません。

架空計画A101で、送る内容、代替相手の返答、配送側の記録を、別々に読めるでしょうか。

代替相手は、試したい返答を再現するための相手役

代替相手は、外部システムの代わりに用意する試験用の相手役です。たとえば受付の返答や、返答が来ない状態を用意し、自社側が何を送り、どう扱うかを確かめるために使います。模擬する対象と、実際に試す自社側の部分を開発会社へ説明してもらいます。

「モック」という言葉が出たら、どの相手の何を代わりにし、どこは実際の部品を動かすのかを聞きます。MicrosoftのAzure向け試験ガイドも、外部依存の模擬と、試験対象そのものを置き換えない区別を説明しています。特定のクラウドや道具を全案件で使うという意味ではありません。

APIの窓口、送る項目と単位、受付と業務完了、応答がないときの基本を確認したい場合は、注文を送る例でAPI連携の仕組みと制約を確かめる記事が入口です。本稿は、それらをどんな相手と環境で試し、何の証拠を受け取るかに絞ります。

代替相手では、受付応答と応答なしの何を試す？

代替相手なら、普段の返答だけでなく、実相手では任意に起こしにくい状態も用意できます。何を再現する計画かと、実際に何を観測したかを分けて読みます。ここでは、別の注文を使った二つの計画を比べます。

代替相手が返す予定の情報と、配送側の受け手記録を、混ぜていないでしょうか。

この節の解説図を原寸で見る

代替相手で通常の注文を送る計画

注文番号は架空注文A101、品目は部品甲、数量は10です。場所と相手は社内試験環境＋代替応答で、用意する返答は「受付応答」です。受付応答を用意する計画です。開発会社へ、送信する項目と相手役の設定、自社側で何を観測するかを聞きます。受付という文字を返す設定があることと、試験を実行してその返答を観測したことは別です。

代替相手で応答なしを起こす計画

注文番号は架空注文A102、品目は部品乙、数量は4です。場所と相手は社内試験環境＋代替応答で、用意する返答は「応答なし」です。応答が来ない状態を用意する計画です。待ち方、表示や記録、次に誰が調べるかなど、今回の仕様で何を確かめるかを聞きます。待ち時間や再送回数はこの例では決めていません。実際の通信障害が起きた記録でもありません。

この二例では外部相手の試験環境を使わない計画条件です。代替相手へ送る計画であって、外部環境を実際に使わず試験が完了した証拠ではありません。A101とA102も、同じ注文を直して再試験した前後ではなく、別の架空例です。数量に単位は設定していません。必要な単位や意味は、実案件の仕様で確かめます。

代替側の設定と、相手の実仕様が合っているかを聞く

代替相手が古い形の返答を返していれば、その相手役との試験が通っても、実相手とのやり取りが合うとは限りません。利用する仕様の版と、要求・返答の項目や形式を、どの方法で照合するかを開発会社へ聞きます。

この入出力の約束を照合する方法は、契約テストと呼ばれることがあります。ここでの契約は、システム間で期待する情報の形のことで、商取引の契約や発注側の受入了承とは別です。形が合う確認だけから、配送側の記録や仕事の完了まで分かったとは判断しません。

外部の試験環境と、受け手の記録を確かめる

外部相手の試験環境は、相手が試験用に使える場所や条件を用意しているかから確認します。サンドボックスと呼ばれる場合もありますが、すべてのサービスに存在する、自由に使える、本番と同じ動きであるとは決め付けません。

外部の試験環境を使えるかと、配送側の記録を誰が照合するかが、つながっているでしょうか。

この節の解説図を原寸で見る

外部相手の試験環境で受け手記録を照合する計画

注文番号は架空注文A103、品目は部品丙、数量は2です。想定する場所は外部相手の試験環境（利用可否未確認）で、その環境の利用についての記録は未確認です。前の二例と別の計画で、実相手との試験を実行した結果ではありません。

この例の模擬返答に当たる値も未確認です。実相手の試験でどんな返答を期待するか、受け手のどの情報と注文を照合するかを、別に定義します。代替例の「受付応答」を、そのまま実相手の返答仕様へ移さないでください。

相手の試験環境を使えるかという双方の合意条件は未確認、受け手記録の照合方法も未確認です。発注担当は配送側へ、試験に使える場所、登録される情報、記録を見られる範囲と確認方法を聞き、開発会社の試験内容とそろえます。

環境が使える場合と、使えないと分かった場合を分ける

利用できると確認できたら、接続先やデータ、実施できる時間や操作の制約、記録を照合する担当を合わせます。試験用の返答と記録が、本番の返答や記録とどう違うかも聞きます。試験用であることだけで、本番とすべて同じとは判断しません。

使えないと確認できた場合は、理由と、代替相手で追加できる確認、残る未確認を分けて説明してもらいます。仕様・相手側の試験報告・別の立会方法などの材料で、どこまで判断できるかを相談します。利用可否の回答がない状態を、「使えない」と確定することも避けます。

試験前に、版・データ・双方の担当をそろえる

同じ注文データでも、対象の版、相手の仕様、試す場所とデータが違えば、結果の適用範囲が変わります。発注担当は、「この条件なら何を確かめられるか」を双方の担当へ説明してもらい、試験前にそろえます。

試す版・相手・データと、実施する人・受け手を確かめる人が、同じ計画に結び付いているでしょうか。

対象版・仕様・接続条件をそろえる

この例では、自社の対象版と相手の仕様の版がいずれも未確認で、認証や接続の条件も未確認です。開発会社へ、どの版と相手のどの仕様に対する試験かを示してもらいます。認証方式や接続先の確認方法も、相手の担当と合わせます。

秘密の鍵や認証情報の実値を、一般の説明資料や公開記事に書く必要はありません。必要な担当が設定方法を確認し、試験の記録では適用した条件を識別できるようにします。本稿は資格情報の設定や実環境の操作を行う手順書ではありません。

データの意味と、期待する返答を合わせる

試験用データの了承は未確認で、期待する返答の定義も未確認です。注文番号が何を識別するか、品目と数量が相手側のどの情報へ対応するかを説明してもらいます。数量の単位や必須条件は、この架空例の数字だけでは決まりません。

実際の試験では、同じ例を両者が説明できるようにし、必要な開始状態、実行する操作、期待する観測をそろえます。相手の既存記録と混ざらないデータの扱いや、試験後の記録をどう整理するかも、利用条件に応じて確認します。Microsoftのガイドは試験データとケースを分けて管理する考え方を示しますが、資料の数値や特定ツールをこの例の条件にはしていません。

送る側と、受け手を照合する側を分けて聞く

自社側の試験実施担当と、配送側の記録を確認する担当は、いずれも未確認です。開発会社が送信記録を持っていても、配送側の記録を確認できる人とは限りません。双方が何を見て結果を返すかを決め、回答の窓口をそろえます。

結果報告の観測・未確認・未実施を読み分ける

報告では、計画の内容と、実行して観測した内容を分けて読みます。対象版、相手の種類、試験環境、注文データ、期待した返答、実際の返答と受け手記録を対応させると、何を判断でき、何が残るかを説明できます。

報告の返答は、どの相手の何を観測したものか。受け手記録まで説明できるでしょうか。

この節の解説図を原寸で見る

予定した返答と、観測した返答を並べて読む

三例の実際の返答は未確認、受け手記録を観測した内容も未確認です。予定欄の「受付応答」「応答なし」が、そのまま結果欄へ入ったとは読みません。結果が書かれていなければ、実施したか、どこを観測したかを確認します。

実相手を試したという説明なら、試験に使った相手と環境、送信した注文、相手の返答、記録の照合方法を示してもらいます。記録があると確認できても、必要な処理がどこまで終わったかは、合意した完了の定義と照合します。代替相手の記録を、配送側の記録として受け取らないようにします。

技術上の結果と、仕事の完了を分ける

三例の技術上の結果は未確認で、仕事の完了を確認した内容も未確認です。通信や形式の確認と、必要な業務記録がそろった確認を、同じ意味の合格へまとめません。どんな条件を満たしたかと、まだ見ていない範囲を説明してもらいます。

返答に応じて、次に依頼する内容を変える

代替相手の範囲だけなら、実相手で確認していない接点を明示してもらいます。環境や記録が不明なら、双方へ確認先と必要な資料を返します。実際の問題が観測されていれば、その注文・条件・期待と観測の違いを渡し、原因を調べる担当と対応を相談します。

受入・保留と、修正後の再確認を相談する

発注側の受入判断は、「試験済み」という言葉や報告書の有無だけでは決まりません。今回満たす必要がある条件に対し、どの証拠があり、どの確認が残るかを、判断する人へ返します。

報告に残る未確認と、発注側が判断する条件を、同じ資料で相談できるでしょうか。

この例では、三つの計画の受入判断はいずれも未確認で、リリースの受入を判断する担当も未確認です。記事側で了承や保留を決めたことにはしません。担当は、必要な範囲と証拠、残る問題と条件を照合して判断します。

問題が見つかったら、対応する人と再確認する範囲を合わせる

三例の問題に対応する担当は未確認で、共有のエラー対応担当も未確認です。送信する側の問題、代替相手の設定、相手の仕様や記録の説明不足では、次に依頼する相手が異なります。原因と判断材料を分け、担当へ説明を返します。

再確認する範囲も未確認です。変更した版・項目・応答の扱いを聞き、元の条件で何を確かめ、関連するどの範囲を見るかを決めます。修正連絡だけを完了の証拠にしたり、前の版の結果を新しい版へそのまま移したりしないようにします。

代替相手の確認だけで今回の条件を満たすのか、外部環境や受け手記録まで必要かは、仕事と求める証拠から決めます。外部の試験環境がない場合も、自動的に合格や不合格へせず、代わりの材料と残る範囲を判断者へ説明します。試験全体の開始・終了条件は、試験を始める前の計画をそろえる方法とも対応させてください。

まとめ：相手・観測・受け手記録を同じ計画へ結ぶ

外部連携テストを受け取る発注担当は、相手が代替なのか実相手の試験環境なのかを確認します。入力と予定した返答、実際の観測、受け手記録を分け、双方の担当と残る確認をそろえることが、判断の入口です。

最初に、開発会社と配送側の担当へ、どんな注文と質問を示すでしょうか。

A101・A102・A103は別々の架空計画で、実施順や修正前後ではありません。代替相手の試験を実相手の受領証明にせず、未取得を拒否・失敗・成功に変えません。代替例の計画条件も、実施済みを示す値ではありません。