テスト設計

テスト設計は、テスト計画で決定した範囲に従い、識別した「テスト条件」を具体的な「テストケース」へと落とし込んでいくプロセスです。主に以下の4つのポイントに分けられます。

1. テスト設計の主な活動

テストアナリストはテスト設計において、以下のような活動を行います。

• テストケースのレベル決定: どのテスト領域で「ローレベル（具体的）」または「ハイレベル（抽象的）」なテストケースが適切かを判断します。
• テスト技法の適用と設計: 必要なカバレッジを確保するためのテスト技法を決定し、テスト条件をカバーするテストケースを設計します。
• テスト環境とデータの識別: テストに必要なテストデータ、テスト環境、インフラストラクチャー、およびツールを設計・識別します。
• トレーサビリティの確立: テストベース（要件など）、テスト条件、テストケース間の双方向のトレーサビリティを確立します。

2. テストケースの設計レベル（ハイレベルとローレベル）

テストケースの抽象度には大きく2つのレベルがあり、状況に応じて使い分けます。

• ローレベルテストケース（具体的なテストケース）
  • 長所: 具体的な手順やデータが記載されているため、経験の浅いテスト担当者でも実行でき、誰が実行しても同じ結果になる（再現性が高い）のが特徴です。
    また、自明ではない欠陥の検出や、監査などの独立した検証、自動化に向いています。
  • 短所: 作成やメンテナンスに非常に多くの労力がかかり、実行時にテスト担当者の創造性を制限してしまう傾向があります。
• ハイレベルテストケース（抽象的なテストケース）
  • 長所: テストのガイドラインとして機能し、実行時にテスト担当者が実データや手順を柔軟に変更できます。
    テスト担当者の経験を活かすことができ、要件プロセスの初期段階で定義できる点や、再利用性に優れる点がメリットです。
  • 短所: 詳細な説明がないため再現性が低く、検証が困難です。また、実行には経験豊富なテスト担当者が必要になる場合があります。

3. テストケース設計で定義すべき要素

テストケースを設計する際は、以下のアイテムを明確に識別・定義します。

• 目的: 観測可能で測定可能な、テスト実行の目的。
• 事前条件: テスト環境の要件や、実行前のシステムの状態など。
• テストデータ要件: テスト実行に必要な入力データや、システム内に準備しておくべきデータ。
• 期待結果と事後条件: 明確な合格/不合格基準と、テスト実行後のシステムの状態や影響を受けたデータなど。
  • ※補足: 期待結果の定義（手動での計算など）は困難でエラーが発生しやすい場合があるため、自動化された「テストオラクル（期待結果を判定する仕組み）」を見つけるか作成することが推奨されています。

4. テスト設計における重要な留意点

• ステークホルダーへの配慮: テストケースは作成者だけでなく、他のテスト担当者や開発者、監査担当者が見ても理解できるように定義する必要があります。
• 幅広い相互作用のテスト: ユーザーインターフェースの操作だけでなく、他のシステムや物理的イベントとの相互作用、またテスト対象間のインターフェース自体もテストするように設計すべきです。
• 静的テストとしての効果: 要求仕様を読み解きながらテストを設計する過程で、要件の抜け漏れや曖昧さなどの欠陥を発見できることが多いため、テスト設計自体が「静的テスト」の一形態として機能します。要件レビューの準備としても非常に有効です。
• 優先度とリスクのバランス: テスト設計にかける労力は、対象のリスクレベルとビジネス価値に見合うように優先度を割り当て、バランスをとる必要があります。

これらを総合し、測定可能な「終了基準」を満たし、後続の「テスト実装」へ進むための準備をすべて整えることがテスト設計フェーズのゴールとなります。