属人化を防ぐ！再現性と網羅性を高めるテスト設計の基本

2025年10月11日 2025年10月11日山崎講師

山崎講師

ITシステムの品質を担保する上で、テストは不可欠なプロセスです。その中でも、システムの根幹をなす振る舞いを検証する「機能テスト」は、最も基本的かつ重要な活動と言えるでしょう。このセクションでは、経験豊富な皆様が既にご存知の機能テストについて、その定義、スコープ、そして関連するテストタイプとの境界を再確認し、共通の理解を構築することを目指します。

第1章機能テストとは何か

機能テストとは、システムの機能が要件仕様通りに正しく動作するかを検証するテスト活動です。その本質は、システムの内部構造や実装方法を問わない「ブラックボックステスト」にあります。

我々が焦点を当てるのは、「システムが何をするか（What）」であり、「どのようにそれを行うか（How）」ではありません。入力されたデータに対して、仕様書に定められた通りの出力や振る舞いが返ってくるか。その一点を、ユーザーの視点から客観的に評価します。

テストのインプットとなるのは、要件定義書や機能仕様書、ユーザーストーリーといったドキュメントです。これらの記述から、システムの期待される動作を抽出し、それを検証するためのテストケースを設計していきます。

機能テストの対象レベル

機能テストは、特定のテストフェーズだけで実施されるものではありません。ソフトウェア開発ライフサイクルの様々なレベルで適用されます。

単体テストレベル
- 個々のモジュールやコンポーネントが持つ特定の機能が、その仕様を満たしているかを確認します。
結合テストレベル
- 複数のモジュールを組み合わせた際に、モジュール間のインターフェースが正しく連携し、結合された機能が期待通りに動作するかを検証します。
システムテストレベル
- システム全体が、エンドツーエンドで要件を満たす機能を提供できているかを評価します。
受け入れテストレベル
- 最終的なプロダクトが、ユーザーの要求やビジネスニーズを満たしているかを、実際の利用者の視点で確認します。

このように、機能テストは開発の初期段階から最終段階まで、一貫してその品質を支える基盤となります。

機能テストと非機能テストの明確な境界

機能テストの役割をより明確に理解するために、非機能テストとの違いを整理しておくことが重要です。両者は品質を測るという目的は同じですが、その評価軸が根本的に異なります。

端的に言えば、機能テストが「要求された機能が実装されているか」を問うのに対し、非機能テストは「その機能がどれだけうまく、効率的に、安全に動作するか」を問います。

観点	機能テスト	非機能テスト
目的	仕様通りに機能が動作することの確認	品質の特性（性能、信頼性、セキュリティ等）の確認
評価対象	システムの「振る舞い」や「何ができるか」	システムの「状態」や「どれだけうまくできるか」
テストベース	要件定義書、機能仕様書	非機能要件、システムアーキテクチャ
問いの例	「ユーザーはログインできるか？」	「1000人のユーザーが同時にログインできるか？」

これら二つのテストは対立するものではなく、互いに補完し合う関係にあります。優れたシステムは、機能が正しいだけでなく、快適で安全に利用できなければなりません。

機能テストは、システムがユーザーやビジネスに対して約束した価値を提供できているかを直接的に証明する手段です。次のセクションでは、この機能テストをいかに効果的かつ効率的に計画し、設計していくか、「よいテスト設計」の原則について掘り下げていきます。

品質を左右する技術：「よいテスト設計」の原則と実践

機能テストの目的と範囲を明確にした上で、次に取り組むべきは、そのテストをいかにして効果的かつ効率的に実施するかの計画、すなわち「テスト設計」です。テスト設計は、単にテストケースをリストアップする作業ではありません。それは、限られたリソースの中で品質目標を達成するための、戦略的かつ分析的な技術です。

このセクションでは、「よいテスト設計」とは何か、その根底にある原則を定義します。

よいテスト設計が持つべき4つの特性

優れたテスト設計は、以下の4つの主要な特性によって評価されます。これらは互いに連携し、テスト活動全体の価値を最大化します。

1. 有効性 (Effectiveness)

テストの最も重要な目的は、欠陥（Defect）を発見することです。有効性の高いテスト設計とは、重大な欠陥や、ユーザー影響の大きい欠陥を発見する可能性が高いテストケースに焦点を当てた設計を指します。すべての機能を網羅的にテストするのではなく、リスク分析に基づき、障害が発生した場合の影響度が大きい機能や、変更が頻繁な箇所を優先的に、そして重点的に検証するアプローチが求められます。

2. 効率性 (Efficiency)

プロジェクトのリソースは常に有限です。効率的なテスト設計は、重複や冗長性を排除し、最小限のテストケースで最大限のカバレッジを達成することを目指します。同値分割法や境界値分析といった古典的な技法から、ペアワイズ法や直交表などの組み合わせテスト技法を適切に活用することで、テストケース数を最適化し、テストにかかる工数と時間を削減します。

3. 保守性 (Maintainability)

システムは一度リリースされれば終わりではなく、継続的に改修や機能追加が行われます。よいテスト設計は、この変化に対応できる構造を持っています。テストケースはモジュール化され、仕様変更があった場合にも、影響範囲の特定と修正が容易でなければなりません。また、誰が読んでも理解できるような明瞭な記述は、将来の回帰テスト（リグレッションテスト）を円滑に実施するための鍵となります。

4. 追跡可能性 (Traceability)

すべてのテストケースは、その根拠となる要件と明確に対応付けられている必要があります。この追跡可能性が担保されていることで、全ての要件がテストされていることの証明（網羅性の証明）が可能になります。また、要件に変更が生じた際に、影響を受けるテストケースを迅速に特定し、修正や追加の要否を判断するための不可欠な情報となります。

よいテスト設計がもたらす価値

これらの特性を備えたテスト設計は、単に品質を保証するだけでなく、プロジェクト全体に具体的な価値をもたらします。

手戻りの削減: 設計段階で欠陥を発見することは、実装後やリリース後に発見するよりも、修正コストを劇的に低減させます。
品質の可視化: テストの進捗とカバレッジが明確になり、ステークホルダーに対してプロダクトの品質レベルを客観的な根拠をもって報告できます。
リソースの最適化:勘や経験だけに頼る場当たり的なテストをなくし、リスクの高い領域にリソースを集中投下できます。

テスト設計は、品質保証活動における設計図そのものです。効果的、効率的、そして持続可能なテストを実現するためには、これらの原則を常に意識することが不可欠です。

次のセクションでは、このテスト設計という活動が、実際のテストプロセス全体の中で、どの位置にあり、どのような役割を担うのかを具体的に見ていきます。

テストプロセスの中核：テスト設計の位置付けと役割

「よいテスト設計」が持つべき特性を理解したところで、次はその設計活動がテストプロセス全体の中で、どのような位置付けにあるのかを正確に把握する必要があります。テスト設計は単独のタスクではなく、先行するプロセスから情報を受け取り、後続のプロセスへと成果物を受け渡す、一連の流れの中に組み込まれています。

標準的なテストプロセスにおける流れ

一般的なテストプロセスは、以下のフェーズで構成されます。テスト設計は、この中で2番目に位置する重要な活動です。

テスト計画
- テストの目的、範囲、アプローチ、リソース、スケジュールを定義します。
テスト分析・設計
- テストの「何を」「どのように」検証するかを具体化します。テストベース（要件定義書など）を分析し、テスト条件を識別し、具体的なテストケースを設計します。
テスト実装
- テスト設計書に基づき、テスト手順の具体化、テストデータの作成、テスト環境の構築、テストスクリプトの作成などを行います。
テスト実行
- 実装されたテストケースを実行し、結果を記録します。期待結果と実際の結果を比較し、相違があればインシデントとして報告します。
テスト完了報告
- テスト活動全体の結果を評価し、終了基準を満たしているかを確認して、関係者にサマリーを報告します。

テスト設計は、抽象的な「計画」を、具体的な「実行」へとつなぐための、不可欠な橋渡し役を担っているのです。

V字モデルにおけるテスト設計

この関係性を、開発プロセスと対比させて示すV字モデルで考えると、より明確に理解できます。

V字モデルでは、各開発フェーズに対応するテスト設計フェーズが並行して実施されます。

要件定義フェーズ → 受け入れテスト設計
基本設計（アーキテクチャ設計）フェーズ → システムテスト設計
詳細設計フェーズ → 結合テスト設計
実装（コーディング）フェーズ → 単体テスト設計

このモデルが示す重要な示唆は、「テスト設計は、開発が完了してから始まるのではない」という点です。むしろ、開発の上流工程（要件定義や基本設計）の成果物をインプットとして、早期に開始されます。

このアプローチは「シフトレフト」と呼ばれ、開発の早い段階で仕様の曖昧さや矛盾といった欠陥を発見することを可能にします。コードが一行も書かれていない段階で、設計上の問題点を指摘できること。これこそが、テスト設計が持つ極めて大きな価値の一つです。

テスト設計のインプットとアウトプット

テスト設計活動の具体的な入出力を整理すると、その役割はさらに明確になります。

インプット
- テスト計画書
- テストベース（要件定義書、機能仕様書、設計書など）
アウトプット
- テスト設計書
- テストケース概要
- 必要なテストデータの種類
- 必要なテスト環境の要件

テスト計画書が示す全体方針に基づき、テストベースを分析して作成された「テスト設計書」は、後続のテスト実装・実行フェーズにおける全ての活動のブループリント（設計図）となるのです。

テスト設計は、テストプロセス全体の品質と効率を決定づける中核的な活動です。開発プロセスと並行して早期に開始することで、手戻りを最小限に抑え、プロジェクトの成功確率を高めます。

さて、テスト設計の重要性と位置付けを理解したところで、次はその成果物である「テスト設計書」が、具体的にどのようなフォーマットで記述されるべきかを見ていきましょう。

標準化への道標：実践的なテスト設計書フォーマット

テスト設計の位置付けを理解した今、その思考プロセスと成果を形にする「テスト設計書」のフォーマットについて解説します。プロジェクトや組織によって最適なフォーマットは異なりますが、標準化された構造を持つことは、コミュニケーションの円滑化、レビューの効率化、そして設計品質の安定化に大きく貢献します。

ここでは、多くのプロジェクトに応用可能な、実践的なテスト設計書の基本構成要素を提示します。

テスト設計書の基本構成

優れたテスト設計書は、テストの目的から具体的なケースまで、必要な情報が過不足なく、論理的に配置されています。以下にその主要な構成項目と、それぞれの目的を示します。

項目	内容	目的・ポイント
改訂履歴	文書のバージョン、更新日、更新者、変更内容の要約を記録します。	誰が、いつ、何を、なぜ変更したのかを追跡可能にします。共同作業や監査において不可欠です。
概要	テスト全体の目的、背景、ゴールを簡潔に記述します。	多忙な関係者が、文書の意図を短時間で把握できるようにするためです。
テスト対象・範囲	テスト対象となる機能、モジュール、画面などを具体的に定義します。「何をテストするか」と同時に「何をテストしないか」を明記することが重要です。	作業範囲を明確にし、関係者間の認識齟齬や、テスト範囲の逸脱（スコープクリープ）を防ぎます。
テスト戦略・アプローチ	どのようなテスト技法（同値分割、境界値分析など）を用いるか、どのテストレベルに焦点を当てるか、自動化の有無など、テスト全体の進め方を記述します。	なぜこの設計に至ったのか、その論理的な根拠を示します。レビュー者が設計の妥当性を評価するための重要な情報となります。
テスト環境	テスト実施に必要なハードウェア、OS、ブラウザ、ソフトウェア、ネットワーク設定、テスト用アカウント、初期データなどを具体的に記述します。	テストの再現性を担保し、テスト実施者がスムーズに作業を開始できるよう準備を促すためです。
テスト観点	対象機能をどのような観点（切り口）で検証するかを洗い出します。これは個別のテストケースよりも一段抽象的な、テストの骨子となる項目です。	テストの網羅性を担保し、仕様の考慮漏れを発見するのに役立ちます。この観点に基づいて、具体的なテストケースが作成されます。
テストケース	個別のテスト手順、入力データ、期待結果を記述します。詳細なケースは別紙（確認項目一覧やパターン表など）として管理することも一般的です。	テスト実施者が迷いなく作業を遂行するための具体的な指示書です。
開始・終了基準	テストを開始するための条件（Entry Criteria）と、テストを完了とするための条件（Exit Criteria）を定義します。	テストプロセスの開始と終了を客観的に判断できるようにし、プロジェクト管理を容易にします。

フォーマットは思考を助けるツール

このフォーマットは、単なる文書作成のためのテンプレートではありません。それは、テスト設計者の思考を体系的に整理し、抜け漏れを防ぐためのフレームワークとして機能します。

各項目を埋めていくプロセスそのものが、対象機能への理解を深め、リスクを洗い出し、より効果的なテストアプローチを導き出すきっかけとなるのです。また、標準化されたフォーマットは、開発者やプロダクトマネージャーといった他の役割のメンバーがレビューを行う際の共通言語となり、的確なフィードバックを促進します。

一貫性のあるフォーマットを用いることで、テスト設計は属人性の高いスキルから、チーム全体で共有・改善できる体系的な技術へと昇華します。

さて、設計書の「型」が定まりました。次のセクションでは、このフォーマットを実際に埋めていくための具体的な「プロセス」について解説を進めます。

構造的アプローチ：テスト設計書作成の5ステップ

テスト設計書のフォーマット、すなわち「型」が定まったところで、いよいよその中身を構築していくプロセスに入ります。優れたテスト設計書は、ひらめきや個人の経験則だけで作られるものではありません。品質と網羅性を担保するためには、体系化された一連のプロセスに従うことが極めて重要です。

ここでは、テスト設計書をゼロから作成するための、標準的かつ再現性の高い5つのステップを解説します。

ステップ1: テストベースのインプUTと理解

全ての設計活動は、インプットの正確な理解から始まります。

まず、テストベースとなる要件定義書、機能仕様書、基本設計書などの関連ドキュメントを徹底的に読み込みます。ここでの目的は、単に書かれていることをなぞるのではなく、機能の目的、背景、制約条件、そしてビジネス上の価値までを深く理解することです。

この段階で仕様の曖昧な点、矛盾、記述漏れなどを発見し、開発者やプロダクトオーナーに質問を投げかけることが、最も早期の欠陥発見活動、すなわち「レビュー」としての役割を果たします。

ステップ2: テスト対象・範囲の明確化

テストベースの理解が深まったら、次にこのテスト設計で扱う「範囲」を定義します。テスト計画書の方針に基づきながら、より具体的に「何をテストし、何をテストしないか」を線引きします。

例えば、「今回は正常系の基本機能のみを対象とし、異常系処理と性能に関するテストは範囲外とする」といったように、スコープを明確に記述します。この作業が、後工程での手戻りや、関係者間の認識のズレを防ぐための防波堤となります。

ステップ3: テスト観点の洗い出し

対象範囲が定まったら、その機能をどのような「観点（切り口）」で検証するかを洗い出します。これは、テスト設計において最も創造性が求められる重要な工程です。

テスト観点とは、個別のテストケースよりも一段抽象度の高い、テストのグループやカテゴリを指します。例えば、ある検索機能のテスト観点を洗い出す場合、以下のようなものが考えられます。

キーワード入力（正常系、異常系、境界値）
検索対象期間の指定
ソート順の指定
絞り込み条件（カテゴリ、価格帯など）
検索結果の表示（件数、ページング）
該当データなしの場合の挙動

このように観点を多角的に洗い出すことで、テストケースの考慮漏れを防ぎ、網羅性を高めることができます。

ステップ4: テスト技法・パターンの選定と設計

洗い出したテスト観点ごとに、最も効果的かつ効率的なテスト技法を選定し、具体的なテストパターンを設計します。

入力値の妥当性を検証する観点 → 同値分割法、境界値分析
複数の条件が複雑に絡み合うロジック → デシジョンテーブル
組み合わせが膨大になるパラメータ → ペアワイズ法、直交表

全ての観点に同じ技法を画一的に適用するのではなく、観点の特性を見極め、最適な武器を選択する分析力が求められます。この段階で、具体的なテストケースの骨子が固まります。

ステップ5: ドキュメント化とレビュー

最後に、ステップ1から4までの結果を、前セクションで定義したフォーマットに従ってテスト設計書としてドキュメントにまとめます。

そして、書き上げた設計書は必ずレビューを受けなければなりません。同僚のテスター、開発者、仕様策定者など、複数の視点からレビューを受けることで、設計の妥当性、論理的な誤り、考慮漏れなどを客観的に評価し、その品質を向上させることができます。受けたフィードバックを元に設計書を修正し、合意形成が取れた時点で、テスト設計は完了となります。

ここまで、テスト設計の基礎となる理論、プロセス全体における位置付け、そして具体的な作成プロセスを学んできました。テスト設計という活動の全体像を掴むことができたはずです。

次の章からは、これらの知識を具体的な成果物へと落とし込む「実践編」に入ります。まずは、あらゆるテストの基本形である「確認項目一覧」の作成から始めていきましょう。

実践的テスト設計：確認項目一覧の作成技法

第2章確認項目一覧

テスト設計の理論とプロセスを理解したところで、この章からは具体的な成果物を作成する実践的なフェーズへと入ります。最初に取り組むのは、あらゆるテストドキュメントの基本形である「確認項目一覧」です。

この一覧は、テスト設計の思考を最もシンプルかつ直接的に表現したものであり、テストの網羅性を担保し、誰が実施しても同じ結果を得られるようにするための、品質保証活動の礎となります。

確認項目一覧とは

確認項目一覧とは、検証すべき項目と、その際の期待される結果をリスト形式で記述したドキュメントです。一般的に、ExcelやGoogleスプレッドシートなどの表計算ソフトで作成・管理されます。

その構造は極めてシンプルで、「何を確認するか（確認項目）」と「どうなれば正常か（期待値）」のペアを基本とします。この単純さゆえに、機能の仕様が比較的単純な場合や、画面の表示項目を網羅的にチェックするようなテストに適しています。

また、手動テストの指示書としてそのまま利用できるだけでなく、自動テストのシナリオを設計する際のベースとしても活用できます。

テスト対象の明確化

確認項目を一つでも書き始める前に、必ず行わなければならないのが「テスト対象の明確化」です。ここでの定義が曖昧だと、後続の作業全体がぶれてしまい、テストの漏れや手戻りの原因となります。

最低限、以下の項目はチーム内で合意形成しておく必要があります。

対象機能: 具体的にどの機能、どの画面、どのコンポーネントをテストするのか。
仕様: テストの根拠となる仕様書やチケットを特定する。仕様書に書かれていること、振る舞いを正しく理解する。
範囲: 「何をテストし、何をテストしないか」を明確に定義する。例えば、今回は正常系の基本操作のみを対象とし、パフォーマンスやセキュリティに関するテストは範囲外とする、といった線引きを行います。

（演習）テスト内容の洗い出し

それでは、具体的な演習を通じてプロセスを体験しましょう。

演習のテーマ: ユーザーログイン機能

非常にシンプルですが、テスト設計の基本要素が詰まった題材です。まずは、このログイン機能について、テストすべき内容を自由に、順序を気にせず洗い出してみてください。

正しいIDとパスワードでログインできるか？
IDが間違っていたら？パスワードが間違っていたら？
IDやパスワードを何も入力しなかったらどうなる？
IDの形式（メールアドレス形式など）はチェックしているか？
パスワードの文字数制限は守られているか？
エラーメッセージは分かりやすく表示されるか？
ログインボタンは最初は押せるか？通信中は押せなくなるか？

このように、思いつくままにテストすべき項目を挙げていくことが、設計の第一歩です。

テスト観点

前項で無秩序に洗い出したテスト内容を、次に「テスト観点」という切り口で整理し、構造化します。テスト観点とは、ある機能を見るための「視点」や「切り口」のことであり、これを用いることで、思考の整理と網羅性の向上が期待できます。

先ほどのログイン機能の例を、いくつかの観点に分類してみましょう。

観点1: 認証
- 正常な認証（正しいIDとパスワード）
- 異常な認証（誤ったIDやパスワード）
観点2: 入力値検証
- 未入力チェック
- フォーマットチェック（メールアドレス形式など）
- 文字数チェック
観点3: 画面表示・UI
- 初期表示（プレースホルダなど）
- エラーメッセージの表示内容・位置
- ボタンの状態遷移

このように観点ごとに分類することで、どの観点からのテストが不足しているかを客観的に評価できるようになります。

確認項目と期待値

テスト観点で整理された骨子を、いよいよ具体的なテストケース、すなわち「確認項目」と「期待値」のペアに落とし込んでいきます。

確認項目: テスト実施者が行う「操作」や「条件」を、具体的かつ簡潔に記述します。「〜な状態で、〜を行い、〜であること」のように、誰が読んでも同じ操作を再現できるレベルの具体性が求められます。
期待値: 確認項目に記述された操作を行った結果、システムが「どういう振る舞いをすべきか」を明確に記述します。「正常にログインできること」といった曖昧な表現ではなく、「ダッシュボード画面に遷移すること」のように、観測可能な事実を客観的に記述することが重要です。

（演習）確認項目一覧の作成

最後に、これまでの演習内容をまとめて、確認項目一覧の形にしてみましょう。

ID	テスト観点	確認項目	期待値
LG-001	認証	登録済みの正しいユーザーIDとパスワードを入力し、ログインボタンをクリックする。	ダッシュボード画面に遷移し、ヘッダーにユーザー名が表示されること。
LG-002	認証	登録済みのユーザーIDと、誤ったパスワードを入力し、ログインボタンをクリックする。	「ユーザーIDまたはパスワードが正しくありません」というエラーメッセージが画面上部に表示されること。
LG-003	入力値検証	ユーザーIDとパスワードを両方とも未入力の状態で、ログインボタンをクリックする。	「ユーザーIDを入力してください」というメッセージがID入力欄の下に、「パスワードを入力してください」というメッセージがパスワード入力欄の下にそれぞれ表示されること。
LG-004	画面表示・UI	ログインボタンをクリックし、サーバーとの通信が開始されてから完了するまでの間。	ログインボタンが非活性状態（クリックできない状態）になること。

このように、観点に基づいて具体的な確認項目と期待値を記述していくことで、体系的で網羅性の高いテストケースが作成できます。

確認項目一覧は、テスト設計の基本であり、多くの場面で有効な手法です。しかし、入力パラメータの組み合わせが多数存在するような複雑な機能においては、この形式ではテストケースが爆発的に増加してしまうという課題もあります。

次の章では、そうした組み合わせの課題を効率的に解決するための、より強力な設計技法である「パターン表」の作成について学んでいきます。

テスト設計の高度化：組み合わせテストとパターン表の実践

第3章パターン表作成

前章では、テスト設計の基本形である「確認項目一覧」の作成方法を学びました。これは直線的な機能の検証に非常に有効ですが、複数のパラメータが絡み合い、その組み合わせを検証する必要がある場合、テストケース数が爆発的に増加してしまうという課題に直面します。

この章では、その「組み合わせの爆発」という課題を解決するための強力な技法である「パターン表」を用いたテスト設計について、その概念から具体的な作成プロセスまでを実践的に解説します。

パターン表とは

パターン表とは、複数の入力項目や条件（因子）と、それぞれが取りうる値（水準）の組み合わせを、体系的に整理し、テストケースを設計するための表です。組み合わせテスト技法を実践する際の、中心的な成果物となります。

確認項目一覧が「手順」を縦にリストアップしていく形式であるのに対し、パターン表は検証すべき「条件の組み合わせ」を網羅的に表現することに特化しています。複雑な条件下でのシステムの振る舞いを、効率的かつ網羅的に検証することが可能になります。

組み合わせとパターン表

なぜパターン表が必要になるのか、その根底にある「組み合わせ」の問題を理解しましょう。

例えば、あるシステムの検索機能に以下の3つの条件があったとします。

OS: Windows, macOS （2通り）
ブラウザ: Chrome, Firefox, Edge （3通り）
ユーザー状態: ログイン済, ゲスト （2通り）

この場合、考えられる全ての組み合わせの総数は、通りとなります。

この程度の数であれば、全ての組み合わせをテストすることも可能かもしれません。しかし、もし条件が一つでも増えたり、それぞれの条件が取りうる値が増えたりすれば、組み合わせの数はあっという間に現実的にテスト不可能な数へと膨れ上がります。この現象が「組み合わせの爆発」です。

パターン表は、この爆発した組み合わせの中から、効果的・効率的に欠陥を発見できるテストケースを選び出すための羅針盤の役割を果たします。

因子・水準

パターン表を作成する上で、最も重要となるのが「因子」と「水準」という2つの概念です。

因子 (Factor)
- テスト対象の振る舞いに影響を与える可能性のある、条件やパラメータを指します。パターン表では、表の列（ヘッダー）に該当します。
- 例: OS, ブラウザ, ユーザー状態
水準 (Level)
- それぞれの因子が取りうる、具体的な値や状態を指します。パターン表では、各列に含まれるセルの値に該当します。
- 例: 因子OSの水準は Windows と macOS

テスト設計の第一歩は、テスト対象の仕様を分析し、この「因子」と「水準」を正確に洗い出すことから始まります。

（演習）因子・水準の洗い出し

それでは、ECサイトのメール送信機能を例に、因子と水準を洗い出す演習を行ってみましょう。

演習のテーマ: プロモーションメール送信機能

この機能には、ユーザーの種別や設定によって、送信されるメールの内容が変化する仕様があります。この機能のテストを設計するために、仕様書から因子と水準を洗い出してみましょう。

仕様1: 会員種別（無料会員、プレミアム会員）によって、メールのフッターが変化する。
仕様2: ユーザーは添付ファイルの受信可否を設定できる（あり、なし）。
仕様3: ユーザーはメール形式をHTML形式かテキスト形式か選択できる。
仕様4: キャンペーン対象者には、特別なクーポンコードが本文に挿入される（あり、なし）。

この仕様から、因子と水準は以下のように整理できます。

No.	因子	水準
1	会員種別	無料会員, プレミアム会員
2	添付ファイル	あり, なし
3	メール形式	HTML, テキスト
4	クーポン	あり, なし

組み合わせの検討

上記の演習で、4つの因子と、それぞれ2つの水準を洗い出しました。この場合の組み合わせ総数は通りとなります。

この16パターン全てをテストすることは、不可能ではありません。しかし、もし因子が10個あれば、組み合わせは1024通りにもなります。全ての組み合わせをテストするのは、品質とコスト、納期のバランスを考えると現実的な選択とは言えません。

そこで、次に考えるべきは「どの組み合わせを優先的にテストすべきか」です。

組み合わせ削減手法

システムの欠陥の多くは、「単一の因子の挙動」もしくは「2つの因子の相互作用」によって引き起こされるという経験則があります。この特性を利用して、テストケースを効率的に削減する代表的な手法がペアワイズ法（All-Pairs Testing）です。

ペアワイズ法は、「全ての因子における水準のペア（2因子の組み合わせ）を、少なくとも1回はテストする」という考え方に基づいています。

全ての組み合わせを網羅する場合と比較して、テストケース数を劇的に削減しつつも、2因子間の相互作用に起因する欠陥の多くを検出することが期待できます。ペアワイズの組み合わせは、手計算で作成することも可能ですが、一般的には専用のツール（例: MicrosoftのPICTなど）を用いて生成します。

（演習）組み合わせの作成

先ほどのメール送信機能の例（全16通り）にペアワイズ法を適用すると、テストケースは例えば以下のように6〜8通り程度に削減できます。

以下は、ペアワイズ法によって生成されたパターン表の一例です。

テストケースID	会員種別	添付ファイル	メール形式	クーポン
PT-001	無料会員	あり	HTML	あり
PT-002	無料会員	なし	テキスト	なし
PT-003	プレミアム会員	あり	テキスト	なし
PT-004	プレミアム会員	なし	HTML	あり
PT-005	無料会員	あり	テキスト	あり
PT-006	プレミアム会員	なし	テキスト	あり

この表を見てください。「会員種別:無料会員」と「添付ファイル:あり」のペアはPT-001で、「会員種別:無料会員」と「添付ファイル:なし」のペアはPT-002でテストされています。このように、全ての水準のペアが、この表のどこかの行で必ず一度は組み合わされています。16通りから約6通りへと、テストケースを60%以上削減しつつ、品質を担保しているのです。

パターン表と組み合わせ削減技法は、複雑な仕様を持つ機能のテストを、体系的かつ効率的に設計するための不可欠なツールです。

さて、確認項目一覧とパターン表という、2つの強力な設計成果物を作成する方法を学びました。最後の章では、作成されたこれらのテスト設計書が「よい設計」であるかを評価するための、「チェック（レビュー）の実践」について解説します。

設計品質を高める最終工程：テスト設計書レビューの実践

第4章テスト設計書チェック

これまでの章で、テスト設計の理論から、「確認項目一覧」や「パターン表」といった具体的な成果物を作成するプロセスまでを学んできました。しかし、設計書は作成して終わりではありません。その設計が本当に「よい設計」であるかを客観的に評価し、品質を保証するための最終工程、それが「テスト設計書チェック（レビュー）」です。

レビューは、設計の欠陥を実装や実行の前に発見できる、最もコスト効率の高い品質保証活動です。この章では、テスト設計書をレビューする際に、どのような観点でチェックすべきか、その具体的なポイントを解説します。

テスト設計書チェックのポイント

効果的なレビューは、単なる誤字脱字の指摘に留まりません。設計の妥当性、網羅性、効率性といった多角的な視点から、その本質的な品質を問い直す行為です。以下に、レビューを行う際の主要なチェック観点を挙げます。

観点1: 妥当性 — 正しいことをテストしているか？

設計されたテストが、そもそもビジネス要求や仕様と合致しているかを確認します。

要件とのトレーサビリティ (追跡可能性)
- 全てのテストケースは、根拠となる要件定義書や仕様書の特定の項目に紐付いていますか？
- 逆に、全ての要件をカバーするテストケースが少なくとも一つは存在しますか？（網羅性の証明）
- 要件に基づかない、過剰なテスト（いわゆる金めっき）は含まれていませんか？
スコープの妥当性
- テストの対象・範囲は明確に定義され、テスト計画と一致していますか？
- 「テストしないこと」が明確にされており、その判断理由は妥当ですか？

観点2: 網羅性 — テストすべきことを十分にテストしているか？

テストケースの量だけでなく、その「質」と「視野の広さ」を評価します。

テスト観点の網羅性
- 機能に対するテスト観点の洗い出しは十分ですか？見落とされている観点（例えば、セキュリティ、ユーザビリティ、エラーハンドリングなど）はありませんか？
テスト技法の適切な適用
- 入力値の検証に、境界値分析や同値分割法は効果的に使われていますか？
- 複雑な条件分岐を持つロジックに対して、デシジョンテーブルなどの技法が検討されていますか？
正常系と異常系のバランス
- ユーザーが期待通りに操作する「ハッピーパス（正常系）」だけでなく、予期せぬ操作や不正なデータ入力に対する「異常系・例外系」のテストが十分に考慮されていますか？

観点3: 効率性 — 賢くテストしているか？

限られたリソースの中で、最大限の効果を上げるための工夫がされているかを確認します。

重複と冗長性の排除
- 実質的に同じ事象を検証している、重複したテストケースは存在しませんか？
- より少ないテストケースで同じ網羅性を担保できるような、組み合わせの工夫はできませんか？
テストの優先度
- テストケースに、リスクや重要度に基づいた優先順位が付けられていますか？（もしスケジュールが逼迫した場合、どのテストを優先すべきかが明確ですか？）

観点4: 明確性 — 誰が読んでも理解し、実行できるか？

テスト設計書は、設計者本人だけのものではありません。他のテスターや開発者、将来の担当者が見ても理解できるものでなければなりません。

記述の具体性と客観性
- 「確認項目」の操作手順は、具体的で誰が実施しても同じアクションが取れるように書かれていますか？
- 「期待値」は、「正常に動作する」のような曖昧な表現ではなく、観測可能な客観的事実として記述されていますか？
テスト実行の実現可能性
- テストに必要な環境やデータは、明確に定義されており、準備可能ですか？

コースの終わりに

この研修テキストを通じて、我々はテスト設計の基礎理論から始まり、確認項目一覧、そしてパターン表という具体的な設計成果物の作成方法を学び、最後にその設計品質をレビューする手法まで、一連のプロセスを旅してきました。

テスト設計は、単なる作業ではなく、品質をソフトウェアに組み込むための創造的かつ知的なエンジニアリング活動です。ここで学んだ原則と技法は、皆様が今後携わるあらゆるプロジェクトにおいて、品質保証の専門家として価値を発揮するための強力な基盤となるでしょう。

技術は常に進化しますが、その根底にある「いかにして品質を確保するか」という問いは不変です。学びをここで終えるのではなく、日々の実践の中でこれらの知識を応用し、磨き続けていくことを期待しています。

セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク

投稿者プロフィール

山崎講師代表取締役

セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。

第1章 機能テストとは何か