構造やコードに対するテストカバレッジは、テスト対象のモデルが比較的明快であるため、表現が容易ですし、既に様々なカバレッジが世の中で使用されています。
例えばコードの場合、次のようなカバレッジでテストカバレッジを表現できます。
- 制御フローに対するカバレッジ
- データフローカバレッジ
- モードやデータに着目した状態遷移カバレッジ
- 例：nスイッチカバレッジ
- 入出力に対する同値パーティションカバレッジや、各種組合せカバレッジ(n-wiseカバレッジなど)
一方、システムテストなどでの、ブラックボックスの要求や仕様に対するカバレッジについては、テスト対象のモデルが複雑・不明瞭であることもあり、カバレッジの表現が適切でない場面をよく見ます。
例えば、そういった場面では、テスト設計の網羅目標として、次のようなカバレッジのみでテストカバレッジを表現する事例をよく見ます。
- 仕様項目（ユーザストーリ、ユースケース、USDMの仕様など）に対する網羅率
- 仕様項目一つ一つに対し、対応するテストを用意できているか
- テストベースに対する網羅率
- テストベース（例えば要求仕様書）の一文一文に対し、テストを漏れなく用意できているか
あるいは、上記より少しだけ踏み込んだレベルで、「画面遷移を網羅できているか」「選択肢を網羅できているか」といった、特に目立つ側面のみのカバレッジで表現している場合もあります。
このレベルのテストカバレッジは、大規模開発でテスト設計を俯瞰把握したり、組織に最低限のテストを求めたりするような、ざっくりとした用途では有効です。
しかし、こうしたカバレッジは、テストの目標やテスト設計の十分性基準を表現するものとしては不足しています。
例えば「仕様項目（例：ユーザストーリ）に対する網羅率が100%である」というテストカバレッジを守らせても、ユーザストーリ→テストのトレーサビリティの関連づけができる程度のことしか保証できません。ユーザストーリに対して適切な網羅ができているかは触れられていない状態です。
カバレッジが不明瞭な場面でのテストカバレッジの表現アプローチ：表現可能になるまでテスト観点を具体化する
ではテスト設計の目標・十分性基準を具体的に明文化したり、指定したりするためにどうすればいいかについてですが、広く有効なアプローチとして「カバレッジを適切に表現可能になるまで、テスト観点を分解する」というものがあります。
具体例として、特定のアプリの画面のテストのカバレッジを表現したい場合、次のようにテスト観点を分解します。
このようにテスト観点を具体化しておくと、「一通りの画面・画面遷移を網羅できていること」といったざっくりとしたカバレッジ表現ではなく、「指定のOSのバリエーションを網羅していること」「アクセシビリティ基準を満たしていること」といった具体的なカバレッジ表現ができるようになります。
なおこのテスト観点の抽出は、マインドマップやテスト観点分析ツリーといった、ズームアウト・ズームインを表現できるモデリングで行うと、カバレッジ表現の点で都合が良いです。標準的なカバレッジ表現をしたいならばテスト観点の抽象度を上げ、具体的な対象のカバレッジ表現をしたいならば抽象度を下げ、といったアプローチが取れるようになります。
