以前から頭の隅にあったのが、統合テストをどうイメージした方が良いかということ。JSTQBでのテストレベルとして、コンポーネントテスト、統合テスト、システムテスト、システム統合テストという用語がある。一般的に使われている単体テストがコンポーネントテストに、結合テストが統合テストに該当するだろう。（ただし、企業やプロジェクトで、そうとも言えないこともある。）
各モジュールのソースに対するテストとしてコンポーネントテストがあり、全体のテストとしてのシステムテストがあることはイメージしやすい。しかし、用語としての統合テストは理解していても、実際のテストでは解決すべき課題が出てくる。
例えば、Aという人なりグループがA1、A2、、、、というモジュールを設計/コーディング。Bという人なりグループがB1、B2、、、、を、Cという人なりグループがC1、C2、、、、を設計/コーディングしているとする。ここでCは、汎用的なモジュールとする。
そんな時、A1とC1やC2との結合テストを行うか？ 行うとして全ての組み合わせを行うか。また、AとBに関係し合うモジュールがあったら、それも全組み合わせテストを行うか、、、、。そもそもAとかBの中での統合テストを行うかなどである。（場合によっては、AとかBの中でのテストを、統合テストと呼ぶかも組織体やプロジェクトで異なるかもしれない。）
机上では全組み合わせテストを実施すべきだろうが、実際にそのようなことは行わない。（少なくとも自分の経験では。） そうだとして、統合テストをどうイメージしたらいいかが頭に隅にあった。
で、春になって、野球のキャンプとかを目にして、スポーツに例えるのが分かりやすいような気がしてきた。つまり、コンポーネントテストは、バッティングや守備などのある意味単純な練習。システムテストは、実際の試合。そうすると、統合テストは、フォーメーションの練習かなと。
バスケットやバレーボール、あるいはサッカーなどのチーム競技でも似たようなものだろう。水泳や陸上競技だと、リレーが近いかもしれない。走/泳順に応じた練習が統合テスト。走る順番や、走者/泳者を誰にするかで組み合わせが増えてくる。
フォーメーション練習では、メンバーの組み合わせを含めて、そう全部の練習をする訳じゃない。試合が近づけば、より実践的な練習にしていくだろう。
結局統合テストも、どの組み合わせをテストするかとか、全体テスト（システムテスト）に向けてのテストを意識すべきだろう。日程との調整や、そもそも統合テストの期間見積りが重要なのは言うまでもない。統合テストのためのダミーモジュール/コンポーネント作成の手間が膨大になりすぎては本末転倒でもある。
統合テストの際に、視点として機能に着目するのがよいと考える。ソフトウェアの単純な結合というよりも、機能テストとの視点。システムテストの前段階にもなる。以前、ここのブログの「”スクラム”の原典「ラグビー方式による新製品開発競争」」でフェーズの重なりに触れたが、PMBOK4版（日本語版ではP21）でもプロジェクトマネジメント視点でのフェーズ重なりの図が示されている。コンポーネントテスト→統合テストとフェーズがばっさり区切られるよりも、2つが重なっていたり、機能実現が追加されるイメージがよいだろう。
また、スポーツの場合に基本的な練習も交えながら試合/試合前に臨む事も、対比的に参考にすべきかもしれない。つまり、必要なコンポーネントテストや統合テストを継続していくことへの意識である。（当然ながら、自動化などで効率的に行うべき。）
参考になるか分からないけど、自分では良い見方と思えている。
