回答。

手動テストによる統合とは、異なるモジュール、サービス、または外部システム間の相互作用を自動スクリプトなしで手動で確認するプロセスです。

問題の歴史:

IT製品の初期の発展では、すべてのシステムがモノリシックに作成されましたが、会社の規模と外部サービスの数が増えるにつれて、統合テストが重要になりました。テスターは次の問いを持ちました：データとアクションがシステム間で正しく通過することをどのように確認するか—例えば、成功した支払いが請求書と会計システムの両方に反映されることです。

問題:

最大の難しさは、完全な機能を持つ環境がないことです：統合は外部サービス、間欠的なAPI、または外部の制限に依存することがあります。さらに、手動テストは統合の接点ごとに非常に労力がかかり、手順のシーケンスでミスを犯したり、重要なカスケード効果を見逃す可能性があります。

解決策:

再現性を保証するために、「スタブ」（mock/stub）を使用したテスト環境を利用します。
テストケースを構造化し、メッセージ、ログ、ステータスのステップバイステップのチェックを記述します。
最初にエッジケース、タイムアウト、統合呼び出しの再試行、システムのエラーへの反応を確認します。

主な特徴:

統合される両側のビジネスロジックを理解する必要がある。
非同期性や状態伝達の誤差を考慮する必要がある。
部分的な障害に対する耐性をサポートする。

着目すべき質問。

テストダブル（test doubles）とは何で、手動統合テストにおいてなぜ必要ですか？

テストダブルとは、統合コンポーネントの模擬（例えば、mock、stub、fake）です。手動テストでは、実際の外部システムが利用できないか、その呼び出しがコストのかかる場合にシナリオを実行するために必要です。

Happy pathだけをカバーした場合、統合がテストされたと見なせますか？

いいえ。エッジケース（接続エラー、不正なデータ形式、タイムアウト、予期しない応答）を必ずテストする必要があります。

データの送信/受信だけを確認することは十分ですか、それとも他に何か必要ですか？

データの内容の正確性、変換、および統合の接点でさまざまなエラーが発生したときのシステムの行動を確認することが重要です。

一般的なエラーとアンチパターン

システムの「自分の」部分だけで作業し、パートナー側の挙動を確認しないこと。
ネガティブシナリオを無視すること。
ログを分析しない、または統合エラーの履歴を蓄積しないこと。

実生活の例

ネガティブケース

テスターはCRMシステムと請求システム間の統合を成功した注文の追加だけで確認しています。同期エラーや取引のスキップは確認していません。

利点:

基本的なシナリオを迅速にカバーできる。

欠点:

統合のエラーは実際のデータでのみ検出されます。

ポジティブケース

テスターはインターネット接続を切断および再接続し、無効なトークンを挿入するテストを作成します。両側のログを検証します。