結合テスト済みと言われたら？点検申込のつながりと結果を確かめる方法
システム開発・連携の結果報告を読む
架空の設備保守会社の社内IT発注担当が、紙の設備点検申込をWeb受付へ移す仕事を進めています。開発会社から「結合テストは済みました」と聞いても、入力した希望日が正しく渡ったのか、受付側に同じ申込が残ったのか、担当への通知まで確かめたのかを、一行の報告からは読み取れません。
この記事では、一件の点検申込を四つの場所へ対応させ、どの仕様と版で、何を入れ、何を期待し、何が実際に起きたかを読む方法を説明します。結果が足りない場合に、開発会社へ聞く技術的な質問と、業務責任者へ聞く受付条件を分け、回答後にどこを確かめ直すかまで整理します。
先に押さえる答え
「済み」という言葉から判断せず、申込画面→希望日判定→受付記録→担当通知のつなぎ目を、同じ申込・仕様・版の報告で追います。予定の期待と実結果を並べ、確認できないつなぎ目は質問と保留する範囲を残してください。結合の結果がそろっても、発注者が業務として受け入れたこととは分けて判断します。
この例の前提
説明用の架空例です。説明の範囲は「開発会社の結合テスト実施報告を読む。実テスト結果ではない。」。実顧客の申込ではありません。三つの条件について、実施したかと実際の結果は確認できていません。通知が届かない場面も、試す条件として置いたもので、起きた障害の報告ではありません。
結合テストは、一つの申込が渡る場所を追って読む
結合テストは、複数の処理や仕組みをつないだときに、値の受け渡しと動きが仕様に合うかを確かめるものです。一つの日付判定が単独で正しく動くことと、その判定が申込画面から受け取った値で行われ、適切な記録や通知につながることは、確かめる対象が違います。
点検申込の希望日は、どこからどこへ渡るのでしょうか。
図の読み取りと、次にすること
申込画面から通知までを指し、開発会社へ、今回の報告がどのつなぎ目までを含むか聞きます。接続先の代わりを使った試験か、実際につなぐ構成だったかも確かめてください。「全体を通した」と聞いた場合も、対象の版とつなぎ先を報告上で特定します。
例えば、画面に入力した日付を受け取る処理と、日付の意味を判断する処理の間では、同じ内容を渡せたかを見ます。日付判定から受付記録へ進む間では、受付条件に合う申込だけをどの状態で記録するかが関係します。記録から通知へ進む間では、誰に何を伝え、通知が遅れたり届かなかったりしたとき、元の申込をどう追うかを確かめます。
一つの希望日判定だけの結果を読む段階は、単体テストの入力・期待・実結果を確かめる方法で扱っています。そこから、画面・記録・通知のつながりへ対象を広げたのが本稿の問いです。
名称だけで範囲を固定しないことも大切です。「内部結合」「外部結合」「総合」という区切りは、今回の開発会社の計画と対象構成に照らして読みます。本稿の四つの場所が、実際にも四つのプログラムや製品として分かれているという意味ではありません。仕様と報告で、どの処理同士の受け渡しを確認したかを説明してもらいます。
仕様・版・入力・期待・実結果を、同じ報告で照合する
まず、結果報告に書かれた対象を、元の仕様や試験項目と対応させます。入力の画面だけでなく、日付判定、記録、通知までのどこが含まれるか、試した条件と結果を読めることが必要です。書式の名前を統一するためではなく、違う対象の資料を同じ試験の記録として混ぜないためです。
この報告は、どの仕様と版の、どのつなぎ目を確かめた記録でしょうか。
この節の解説図を原寸で見る図の読み取りと、次にすること
申込画面から通知までの四つの場所を、仕様と結果報告の同じ対象へ対応させています。発注担当は、どの版・入力でどのつなぎ目を見たかを開発会社に指してもらいます。実結果を読めない場所は質問として返し、資料があることだけで接続成功とは判断しません。
- 対象と仕様を特定する申込から通知までの対象範囲と、その期待を決めた仕様の版を照合します。今回の教材で契約や要求の版は未確認です。資料名だけでなく、対象の項目や変更が対応するかを聞いてください。
- 試した場所と、つなぐ相手を読むどの構成とデータで試し、接続先は本物か代替かを読みます。現在の試験環境は未確認です。代替の相手で値の受け渡しを確かめた結果を、実際の通知先まで届いた結果へ広げません。
- 入力と、その前の状態をそろえる何を入力し、受付記録や通知の状態をどう用意したかを確認します。同じ希望日でも、別の申込や別の開始状態の結果を混ぜると、途中の値を追えません。現場の実顧客データを持ち出すのではなく、関係を保った確認用の例を相談します。
- 期待と実際の結果を、つなぎ目ごとに比べる期待は実行前に何を正しいと考えたか、実結果はその条件で何を見たかです。画面の案内、日付判定への入力、受付記録、通知の記録のどこを根拠にしたかを、報告と対応させます。
- 確認できない範囲の理由を聞く実施していないと分かった項目は、その理由と次の確認へ結びます。実施の記録を受け取っていないだけなら、実施したか自体が不明です。両者を分けて質問し、結果を読むまでは該当範囲を合格扱いにしません。
資料がそろっていることと、動いたことを分ける
仕様や報告のファイルが届いただけでは、そこに書かれた入力で実行されたことや、期待と実結果が一致したことは分かりません。同じ対象を資料の中で指し、実行と結果の記録へ結び付けます。
三つの別条件で、期待案と未取得の結果を分ける
下の三つは、同じ試験を修正前後で並べたものではありません。日付の違いと通知先の問題という、別の条件を相談する架空例です。ここにある期待も質問のたたき台で、合意した仕様や実行済みの結果ではありません。年や受付資格など、例にない条件を補って合否を決めません。
暦にある日・ない日・通知が届かない場面では、どの受け渡しを分けて聞くのでしょうか。
この節の解説図を原寸で見る図の読み取りと、次にすること
三つは、日付の違いと通知先の問題を相談する別々の条件です。発注担当は、それぞれの入力、記録や通知の期待、その根拠を開発会社と業務責任者へ聞きます。現在は試験を実施したかも実結果も分からないので、未実施・失敗・成功のいずれにも置き換えず、条件と結果を分けて具体化してください。
暦にある希望日
説明用の入力は「4月30日」です。
画面から日付判定へ渡す期待案は「日付判定へ同じ値を渡す想定」。日付判定から記録へ進む期待案は「受け付け条件に合う場合のみ記録する想定。受け付け条件自体は未確認」です。
記録から通知へ進む期待は未確認です。
この条件で、画面・日付判定・受付記録・担当通知の実結果は、いずれも未取得です。試験を実施したかも未確認です。
「4月30日」は暦にある日を表す説明です。その日を予約として受け付ける条件まで決まった例ではありません。画面に入力した内容と、日付判定へ渡った内容を開発側に対応させてもらい、受付条件は業務責任者の根拠と照合します。記録した後にどの通知を期待するかも、別に具体化してください。
暦にない希望日
説明用の入力は「4月31日」です。
画面から日付判定へ渡す期待案は「日付判定へ同じ値を渡す想定」。日付判定から記録へ進む期待案は「記録しない想定だが連携時の仕様確認が必要」です。
記録から通知へ進む期待は未確認です。
この条件で、画面・日付判定・受付記録・担当通知の実結果は、いずれも未取得です。試験を実施したかも未確認です。
4月31日という暦にない入力では、記録しないという想定を、実際の連携仕様と照合します。画面だけで止めるのか、日付判定の結果を受けて止めるのか、利用者へどう案内し、受付記録をどの状態にするのかを確認します。エラー表示を見ただけで、記録や通知が行われなかったと推測しません。
通知先に届かない場合
説明用の入力は「有効日付の申込（具体日時未確定）」です。
画面から日付判定、日付判定から記録、記録から通知へ進む期待は、いずれも未確認です。
この条件で、画面・日付判定・受付記録・担当通知の実結果は、いずれも未取得です。試験を実施したかも未確認です。
通知先へ届かない状況を試すなら、どこで届かなくなる条件を作り、記録側に何が残り、誰が未達を知るべきかを先に相談します。再送するのか、担当者が対応するのか、重複通知をどう避けるかも、仕様を確認して期待を具体化します。この例から、再送が実装済み、記録は成功済み、実際に未達が起きた、とは判断しません。
不明な欄を、成功や失敗で埋めない
実結果が取れていない状態から、未実施・不合格・合格のどれかを選ぶことはできません。「未実施」と回答があった場合も、実行できなかった理由と残る範囲を読み、失敗した結果と混ぜないようにします。
技術的な記録と業務条件を、答えられる相手へ返す
報告に読めない欄があったら、単に「資料をもっとください」と戻すより、どの入力とつなぎ目の何が分からないかを示します。技術的な記録と、業務として期待する条件では、答えられる相手や必要な材料が違うためです。役割を示すことは、実際の担当者や対応の了承が決まったことではありません。
不足しているのは実行の記録でしょうか、それとも業務上の条件でしょうか。
この節の解説図を原寸で見る図の読み取りと、次にすること
対象版や実結果の記録への質問は開発会社へ、申込の受付や通知で必要になる業務条件への質問は業務責任者へ対応させています。発注担当は同じ申込と報告を示し、どの質問に誰が答えられるかを相談します。回答の根拠を同じ条件の報告へ戻し、実際の担当や了承が決まったとは先に扱わないようにしてください。
対象や実結果が分からないなら、開発会社へ
「4月30日の例で、画面から日付判定へ渡った値と、受付記録に残った内容はどこを見れば対応しますか。対象の版と環境も教えてください」のように聞きます。通知まで含めたか、接続先の代替を使ったか、実施していない範囲と理由は何かを、同じ報告へ結びます。
実結果の根拠が得られれば、合意した期待と照合する段階へ進みます。別の版の資料しかない、接続先を含めていない、実施したか確認できないという回答なら、その範囲の結論を保留し、必要な確認と返却予定を実際の相手へ相談します。
何を正しい結果とするかが不明なら、業務責任者へ
暦にある日をどの条件で受け付けるか、暦にない日をどう案内するか、通知が届かないと受付の仕事がどこで止まるかを聞きます。紙で扱っていた規則や受付担当の仕事と対応させ、期待の根拠を特定します。記事の例を自社の確定仕様にしません。
業務上の条件が明らかになったら、開発会社と、その条件をどの入力・状態・つなぎ目で確かめるかを合わせます。条件が未合意なら、試験結果を集めるだけでは正しさを比べられない範囲が残ります。必要な判断とその確認先を示し、対象範囲を保留します。
記録と通知の担当が別なら、同じ申込で話をつなぐ
通知先や共通の仕組みを別の担当が管理している場合は、開発窓口から確認先をつないでもらいます。誰が接続先の状態を示し、誰が結果を返すかを相談してください。申込の内容、対象版、試した条件を対応させ、別々の「こちらは正常」という回答だけで全体を合格にしません。
回答・修正を、同じ条件の報告と再確認へ結び直す
回答が来たら、報告に一行を足すだけで終えず、どの仕様・入力・期待・実結果が変わるかを読みます。実施したことが分かった場合、仕様を変える場合、不具合を直す場合では、次に確かめる内容が異なります。ここで説明するのは回答後の進め方で、この架空例に回答や修正結果が届いたという意味ではありません。
回答や修正を、どの入力とつなぎ目の結果へ戻すのでしょうか。
図の読み取りと、次にすること
回答が対象のつなぎ目へ答えているかを読み、修正や条件変更があれば、開発会社と試す入力・開始状態・比較する期待を合わせます。古い版の結果を、新しい版でも成立した結果として使わないようにしてください。
同じ条件で再確認した結果は未確認です。不具合の件数も未確認で、ゼロ件と分かった状態ではありません。件数を受け取った場合も、どの条件を実施し、何が残り、業務へどう影響するかを読む必要があります。
実施記録が得られたら
対象の版と環境、入力、期待、実結果の対応を確認します。期待と違う結果なら、その相違と影響を開発側へ返します。記録がそろったことと、期待を満たしたことを分け、必要な判断ができる内容かを確かめてください。
仕様の条件を変えるなら
旧条件と新条件を区別し、変える理由と対象をそろえます。以前の結果は、その時の条件での結果として残します。新しい受付条件や通知方法に合わせた入力と期待を具体化し、必要な試験と役割を相談します。
不具合を直したと連絡が来たら
不具合を見つけた条件と、修正版での同じつなぎ目の結果を対応させます。影響が記録や通知など周囲にも及ぶなら、どの範囲を追加確認するかを相談します。再確認の対象を広げる判断は、変更の影響と業務のリスクを読んで行い、何でも最初から繰り返すことを目的にしません。
結合の結果と、発注者の受入・契約上の検収を分ける
この例の結合テストの合否は未判定です。発注者が業務として受け入れた結果も未確認です。単体の結果、連携の結果、業務上の受入、契約上の検収は、それぞれ何を確認した判断かを分けて記録します。
連携の報告を読めたら、業務の受入まで終わったのでしょうか。
図の読み取りと、次にすること
開発側の結果を、次に行う業務確認の条件や残件へ結びます。受付担当の仕事、役割ごとの操作、やり直しや例外の確認など、発注側が必要とする確認は、対象と根拠をそろえて別に進めます。
試験前に対象や担当、準備と開始・終了条件をそろえる段階は、点検申込をWeb化する前のテスト計画を参照してください。試験に使う入力や開始状態を作る段階は、架空の顧客・商品と開始状態をそろえる方法につながります。
発注者自身が通常・入力違い・やり直しの操作で業務を確かめる方法は、発注者の受入テストの進め方で扱います。契約上の納品物と受け入れ方を発注前に合わせる場合は、納品物と検収条件をそろえる方法で確認してください。本稿の連携報告を読むだけで、これらの判断が完了するわけではありません。
まとめ：一件の申込で、受け渡しと結果を指して聞く
最初にどの報告を選び、何を指して質問すればよいでしょうか。
図の読み取りと、次にすること
開発会社に、今回の対象版で、一つの入力が四つの場所へどう渡ったかを説明してもらいます。業務条件の根拠がない部分は業務責任者にも聞き、何が分かれば判断を戻せるかを明確にしてください。
読む順序は、対象の範囲と版、入力と開始状態、事前の期待、実際に見た結果、確認できない範囲と次の対応です。同じ資料の順序に合わせる必要はありませんが、同じ一件を追える対応が必要です。合格数だけで省略せず、報告の根拠を指して話せる状態にします。
今日の最初の一歩
開発会社の結合テスト報告から、一つの点検申込を選びます。画面・日付判定・受付記録・担当通知を指し、仕様と版、入力、期待、実結果を同じ順に確認してください。読めない場所があれば、質問と返し先、保留する範囲を残します。
参照資料と説明の範囲
- 会計検査院：平成26年度決算検査報告「各府省等における情報システムに係るプロジェクト管理の実施状況等」 — 「開発・テスト工程」の、計画の内容・データの適切性と実施状況の報告を確認する記述を参考にしています。過去の政府調達に関する説明で、民間の全案件に同じ手続きや法的義務を課すものとして扱っていません。
- 外部ソフトウェアの更新で、テスト実施を示す資料を受け取るかを相談した本人の投稿 — 本人の質問を、発注側が試験の中身をどう確認するかという悩みの一例として参照。回答者の助言を投稿者の結果へ移していません。
必要箇所を2026年10月23日に確認しました。設備保守会社と三つの条件は本稿の架空例です。対象版、実行、通知、合否、承認の実績を示していません。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。
