単体テストでは自分たちの範囲だけで確認できても、結合テストになると、相手先との調整が必要になることがありました。
私が結合テストで特に気をつけていたのは、
- 相手先と認識を合わせてからテストすること
- 接続先が本番機ではないことを確認すること
の2点です。
システム同士を接続して確認する場合、自分たちの準備だけが終わっていてもテストできるとは限りません。
また、接続先を間違えれば、意図していない環境へ処理を行うことにもなりかねません。
この記事では、私が結合テストを経験する中で特に意識していた、相手先との調整と接続先確認について紹介します。
なお、結合テストの進め方や環境構成は、会社やプロジェクトによって異なります。ここで紹介するのは、私が業務システム開発で経験した範囲の内容です。
結合テストとは
結合テストは、モジュールなどを組み合わせ、インターフェースや相互処理が正しく動作するかを確認するテストです。
JSTQBの「Foundation Level シラバス」では、「コンポーネント統合テスト」はコンポーネント間のインターフェースや相互処理、「システム統合テスト」は対象システムと他のシステム・外部サービスとのインターフェースに焦点を当てると整理されています。
現場によって「結合テスト」という言葉が指す範囲には違いがありますが、私が経験した結合テストでは、単純に一つのプログラムが動くかを見るだけではなく、接続した先と正しくやり取りできるかを確認する場面がありました。
結合テストでは相手先との調整が必要だった
私が結合テストで単体テストとの違いを感じたのが、相手先との調整です。
自分たちだけでテストできる場合とは違い、相手側との接続が必要になると、自分たちの都合だけでは進められません。
相手先と認識を合わせたうえで、テストを進める必要がありました。
実際の調整内容はシステムやプロジェクトによって異なります。
接続先が本番機ではないかを確認していた
結合テストで特に意識していたのが、今から接続しようとしている先が本番機ではないかという確認です。
業務システムでは、開発環境や検証環境、本番環境など、複数の環境を使い分けることがあります。
そのため、接続先を見ただけで安心せず、テストを行う環境として正しいのかを確認していました。
これは、実際に本番機へ誤接続した経験があるという意味ではありません。
結合テストを実施するときに、間違えてはいけないポイントとして確認していたということです。
接続先を間違えると意図しない環境に処理する可能性がある
接続先の確認を重視していた理由は、接続する環境を間違えると、想定していない場所へ処理を行う可能性があるためです。
テストのつもりで操作していても、接続先が違えば、その処理が行われる環境も変わります。
特に外部との連携がある場合は、
「接続できたからそのままテストを始める」
のではなく、どこへ接続しているのかを確認してから実施することを意識していました。
これは結合テストに限った話ではありませんが、相手先との接続が発生する結合テストでは、私が特に気をつけていたポイントです。
結合テストは「動くか」だけを確認する工程ではなかった
結合テストというと、複数のプログラムやシステムをつないで、正しく動くかを確認する工程という説明がまず浮かびます。
もちろん、それ自体は重要です。
ただ、私が実務で結合テストを経験して感じたのは、実際にテストできる状態を作るところまで含めて考える必要があるということでした。
単体テストよりも関係する範囲が広がる分、プログラムの動作以外にも気をつけることが増えた工程でした。
まとめ：結合テストでは相手先と接続先を確認していた
私が結合テストで特に気をつけていたのは、
- 相手先との調整
- 接続先が本番機ではないことの確認
でした。
結合テストでは、自分たちのプログラムだけを確認して終わるとは限りません。
相手先との接続が必要になれば、調整も必要になります。
また、テストを始める前には、どの環境へ接続しているのかを確認することを意識していました。
私にとって結合テストは、単に「つないで動くかを見る」だけではなく、相手先や接続環境も含めて確認しながら進める工程でした。
