回答。

統合手動テストは、ソフトウェアライフサイクルの重要なステップであり、モジュールテストの後に行われます。その目的は、システム内の個々のモジュールやコンポーネントが正しく相互作用していることを確認することです。

質問の背景: もともと、ソフトウェアのテストは段階的に行われていました：最初に個々のモジュール（ユニットテスト）が確認され、その後、システム全体がテストされました。しかし現実には、多くの重大なバグがモジュール間の接点で発生することが分かりました。統合テストの必要性が生じ、これは手動でシステムのさまざまな部分の動作の不整合を特定します。

問題: 主な難しさは、モジュール間の相互作用シナリオが十分に検討されていないことや、忘れられた相互依存関係です。これにより「見えない」バグが発生します：孤立したテストでは正常に動作しますが、統合後にエラーが発生します（例えば、APIとデータベース間のデータ処理の不具合）。

解決策: 効果的な統合手動テストの実施には次のことが含まれます：

システムアーキテクチャの分析とコンポーネントの相互作用マップの作成。
ユーザーシナリオや境界データに基づく統合テストケースの開発。
部分的な障害のモデル化（例えば、サービスの一部が失敗した場合）およびシステム全体の反応の評価。
結果の文書化とバグ間の依存関係の記録。

主な特徴：

現行のアーキテクチャ図の維持。
システムの各部分間のすべての隠れたおよび明示的な依存関係の考慮。
モジュール間の接点でのデータ転送および変換シナリオへの特別な注意。

トリッキーな質問。

統合手動テストとシステム手動テストの違いは何ですか？

統合テストは特定のモジュール間の接続のテストに焦点を当て、システムテストはビジネス機能の観点からシステム全体の検証に焦点を当てます。

統合テストでは実際の外部サービスを使用すべきですか、それともエミュレーターで十分ですか？

重要な統合には実際の環境が望ましいですが、エミュレーター（モック/スタブ）から始めることも可能です。最終的なテストは、PROD環境にできるだけ近い環境で実施するべきです。

すべての統合エラーは自動化を通じてのみ特定できますか？

いいえ、一部の欠陥は、テスト担当者がデータ交換のビジネスロジックや、自動化にカバーされていないユーザーシナリオの明らかでない問題を見つけるときにのみ手動で見つかります。

よくあるエラーとアンチパターン

統合ポイントの明確なリストがないこと。
環境を隔離せずにテストを実施すること。
統合テストケースの詳細が不十分であること。

実生活の例

ネガティブケース

支払いモジュールと注文モジュール間の統合テストは、他のすべてのテストの後に実施され、別途文書化されていませんでした。

利点:

テストケースの準備にかかる時間を節約。
複雑な調整なしでテストを迅速に開始。

欠点:

二重課金に関連する重大なバグが本番環境に漏れ出す。
最後の瞬間に見つかったバグを修正するためのリリースの遅延。

ポジティブケース

統合シナリオは最初に文書化され、テストデータはユーザーの実際のタスクにできるだけ近づけられました。