大規模な開発では、抽象レベルの高いテスト設計（いわゆるテストアーキテクチャ設計が代表例）を通して、大規模なテストを中小規模のテスト要素に分割するアプローチがとられます。
例えば次ようなものです：
- システムオブシステムズのレベルで、各企業組織など独立性のあるプロジェクトごとにどうテストを分担するか分担設計する
- プロジェクト全体のレベルで、システムテスト、各結合テスト、ユニットテスト等をどうするかテストレベル設計を行う
- 各テストレベルごとに、どのようなテストタイプやテストコンテナ（例えばセキュリティテスト、性能計測、周辺機器接続テストなど）を構成するかテスト設計する
この抽象レベルの高いテスト設計では、現場や教材によって「分割するテスト要素を何にするか」にバリエーションがあります。例えばテストタイプだったり、テストコンテナだったり、テストスイートだったりといった感じですす。
これについて一点注意があるのですが、その「テスト要素」をテストケースセット（テストケースのグループ）にすると危うい場合があります。
理由：手動のテストケースは「全て実施されOKになること」が保証されない
理由ですが、設計した手動テストのテストケースは、全て実施されOKになるとは限らないためです。
テストの現場経験を長く積んでいる方なら自明だと思いますが、例えば大規模な手動テストでは、以下のような対応が行われることが珍しくありません：
- リリース間際で仕様変更を行った際に、変更部分とその影響範囲に特化してテストケースの一部を抜き出しテストする。テストケースのフルセットの再実施はしない
- 開発遅延中のデバッグで、デバッグ部分に対するテストを探索的に実施する。テストケースの厳格な再実行はしない
その他、リリースに追われている状況下で制約でテストがブロックされている状態に対し、テストケースが求めるテスト条件を一部緩和してテストを進めるといった対応が行われることもあります。
上記のような対応下では、リリース版のソフトウェアテストに対して、設計したテストケース全てをフル実行してOKとなることが保証されません
代わりに、直面した制約（例えばリリースが迫っていて工数確保できない）に対応しながら、テストの責務に基づいてテストの取捨選択・補完を行います
そうした各テスト要素ごとに柔軟な状況や制約対応を行うためには、各々のテストの責務を自明にする必要があります。ここでいう「テストの責務」は、具体的には以下で構成されるものです：
- テストの目的
- テストのスコープ
- テストの十分性についての目標や基準
- 対応すべきテストの課題
ここから導き出される留意点ですが、テスト設計でテストケースやテストケースセットまで成果物を落とし込むと、上記のような責務情報がアウトプットから抜けてしまします。
この責務情報の欠落は、十分に細分化された詳細なテスト設計や自動テストでは問題にはなりにくいです。ただ抽象度の高いテスト設計で欠落させると、工数不足などでテストケースを取捨選択する際に、上位のテスト設計で欠落した目的や責務をサルベースする作業が発生することになります。
一応、各テストケースの優先順位を設定したり、横断的な選択基準を設けたりすることで、テストケースセットの状態でもある程度制約対応できるようになります。ただこのアプローチは細かな調整に限界があり、テスト規模に対してスケールしなくなります。
ですので、抽象度の高いテスト設計では、個々のテスト設計要素ごとに「テストの責務」を明確にすることが重要になります。
アーキテクチャ設計をメタファーにテストアーキテクチャ設計を解説する際の注意点
テストアーキテクチャ設計は、通常のアーキテクチャ設計をメタファーに解説されているのをしばしば見ます。
これについて注意点があるのですが、アーキテクチャ設計の最終的な成果物であるコードは、作れば作った通りの動作をします。しかしテストアーキテクチャ設計の最終的な成果物であるテスト実装成果物は、手動テストならば作った通り実行されるわけではありません。その先の状況・制約対応も加味する必要があります。いうなれば、アーキテクチャ設計は構造の設計をしていますが、テストアーキテクチャ設計はテスト設計活動の設計をしているのです。
メタファーとして活用する際には、この差異に注意が必要だと思います。
