テスト設計とは？基本的な流れから技法・サンプルまで初心者向けに解説

ソフトウェア開発の現場で「テスト設計」という言葉を耳にしたことはありますか？テスト設計とはテストケースを作成する前に行う重要な工程ですが、具体的に何をするのか、どこから手をつければよいのか、初めての方には分かりにくいかもしれません。

この記事では、テスト設計の基本的な考え方から具体的な作業内容、代表的な技法、実践的なサンプルまで分かりやすく解説します。この記事を読むことで、テスト設計の全体像を理解し、実際の業務で活用できるようになります。

テスト設計とは？

テスト設計とは、テスト分析で明確にした「何をテストするか」をもとに、「どのようにテストするか」を具体化する作業です。

ソフトウェアをテストする際、まずテスト分析で「何をテストすべきか」(テスト条件)を明確にします。その後、テスト設計でテスト技法を用いながら、具体的なテストケースを作成します。

テスト設計は、単体テスト、結合テスト、システムテスト、受け入れテストなど、どのテストレベルでも行われる活動です。規模や目的は異なっても、テスト分析の結果を具体的なテストケースにする工程は必ず存在します。

テスト分析とテスト設計の違い

「テスト分析」と「テスト設計」は混同されやすいですが、明確に異なります。

• テスト分析：「何をテストすべきか」を明確にする（テスト条件の分析、優先付け、網羅基準の設定）
• テスト設計：「どのようにテストするか」を具体化する（テスト技法の適用、テストケースの作成）

例えば、「入力された年齢に応じて料金を算出する機能」を考えてみましょう：

• テスト分析での成果物：「大人料金・子供料金が正しく区別されること」「境界値で正しく切り替わること」といったテスト条件
• テスト設計での成果物：「年齢が17歳の場合に500円(子供料金)と表示されること」「年齢が18歳の場合に800円(大人料金)と表示されること」といった具体的なテストケース

料理に例えるなら、「何を作るか、どんな味にするか」を決めるのがテスト分析、「レシピを具体的に書く」のがテスト設計に相当します。

ソフトウェアテスト全体の流れ

テスト設計がどこに位置づけられるのか、ソフトウェアテスト全体の流れを見てみましょう。

一般的なテストプロセスは、以下の工程で構成されます：

1. テスト計画：テストの目的、範囲、スケジュール、リソースなどを決める
2. テストのモニタリングとコントロール：すべてのテスト活動を継続的にチェックし、実際の進捗をテスト計画と比較する(モニタリング)。テストの目的を達成するために必要な行動をとる(コントロール)
3. テスト分析：「何をテストするか」を明確にする(テスト条件の分析、優先付け、網羅基準の設定)
4. テスト設計：「どのようにテストするか」を決める(テスト技法の選択、テストケースの作成)
5. テスト実装：テストケースを実行可能なテスト手順に具体化し、テスト手順書や自動化スクリプトを準備する
6. テスト実行：実際にテストを実行し、結果を記録する
7. テスト完了：テスト結果を評価し、報告書を作成する

テスト設計は、この中でテスト分析の後、テスト実装の前に位置します。なお、テストのモニタリングとコントロールは、テスト計画からテスト完了まで継続的に実施される活動です。

テスト分析とテスト設計の関係

ただし、実際のテストプロセスでは、これらの工程が必ずしも順番通りに進むわけではありません。

規模の小さい開発プロジェクトなど、テスト分析とテスト設計に該当する活動を区別せずまとめて行われる場合もあります。また、テスト設計を進める中で新しいテスト条件に気づき、テスト分析に戻って条件を追加するなど、工程間を行き来することもよくあります。

例えば、テストケースを作成している最中に「この条件も確認すべきだ」と気づいた場合、テスト分析に戻ってテスト条件を追加します。このように、テスト設計とテスト分析は相互に影響し合いながら進めていくことが実践的なアプローチです。

テスト設計の重要性

テスト設計を行わずにテストを実施すると、どのような問題が起きるのでしょうか？また、テスト設計を行うことで、どのようなメリットがあるのでしょうか？

テスト設計なしの問題点

テスト設計を行わずにテストを実施すると、以下のような問題が発生します：

• テストケースが場当たり的になる：体系的な設計がないため、テストケースの作成が非効率
• テストの重複や漏れが発生：同じようなテストを何度も作成したり、重要なパターンを見逃す
• テストケースの根拠が不明確：なぜそのテストケースが必要なのか、後から説明できない
• 保守性が低い：仕様変更時に、どのテストケースを修正すべきか分からない

テスト設計ありの効果

一方、テスト設計を行うことで、以下のメリットがあります：

• 効率的にテストケースを作成できる：テスト技法を使うことで、網羅的かつ無駄のないテストケースを作成
• テストケースの根拠が明確：テスト技法の適用理由を説明できる
• 保守性が高い：仕様変更時に、影響範囲を特定して修正しやすい
• レビューしやすい：テスト設計の考え方を共有でき、チーム全体でテストの質を向上

テスト設計の具体的な作業内容

テスト設計では、具体的にどのような作業を行うのでしょうか？テスト分析で明確にされたテスト条件をもとに、以下の流れで作業を進めます。

1. テスト条件に基づくテスト技法の選択

テスト分析で明確にされたテスト条件に対して、適切なテスト技法を選択します。

テスト技法とは、効率的にテストケースを作成するための「型」のようなものです。代表的な技法には以下があります：

• 同値分割法：入力値の範囲を同じような特性のグループに分ける
• 境界値分析：範囲の境界(最小値、最大値)をテストする
• デシジョンテーブルテスト：複数の条件の組み合わせをテストする
• 状態遷移テスト：システムの状態が適切に遷移するかをテストする

どの技法を使うかは、テスト条件の特性によって決まります：

• 入力値に範囲がある場合（例：「年齢の境界値を確認する」というテスト条件）：同値分割法や境界値分析が有効
• 複数の条件の組み合わせを確認する場合（例：「割引適用条件の組み合わせを確認する」というテスト条件）：デシジョンテーブルテストが有効
• システムの状態が変化する場合（例：「注文ステータスの遷移を確認する」というテスト条件）：状態遷移テストが有効

テスト技法については、次のセクションで詳しく解説します。

2. 選択した技法を用いたテストケースの具体化と構造化

選択したテスト技法を適用して、テストケースを具体化し、実施しやすい形に構造化します。

テストケースの具体化

選択したテスト技法を適用して、具体的なテストケースを作成します。

例えば、「年齢の境界値を確認する」というテスト条件に対して、境界値分析を適用すると：

• テスト条件（テスト分析の成果物）：「18歳未満と18歳以上で料金が正しく切り替わること」
• テストケース（テスト設計の成果物）：「年齢が17歳の場合に500円と表示されること」「年齢が18歳の場合に800円と表示されること」

このように、抽象的なテスト条件を、具体的なテストケースに落とし込みます。

テストケースの構造化と整理

作成したテストケースを、実施しやすい形に構造化します。

JSTQBの定義によると、テストケースには以下の要素が含まれます：

1. テスト対象：何をテストするか（機能名、画面名など）
2. 事前条件：テスト実行前の状態
3. 入力値（アクション）：どのような入力やアクションを行うか
4. 期待結果：どのような結果になれば正常か
5. 事後条件：テスト実行後の状態

これらの要素を明確にした上で、テストケースを以下のように整理します：

• グルーピング：関連するテストケースをまとめる
• 優先順位付け：重要度や実施順序を決める
• トレーサビリティの確保：テスト条件とテストケースの対応関係を明確にする

なお、テストケースを実行可能なテスト手順に具体化するのは、次の工程であるテスト実装の役割です。テスト設計では「何をテストするか」を定義し、テスト実装で「どう実行するか」の詳細な手順を作成します。

テストケースの表は、後ほどサンプルで具体的に示します。

代表的なテスト設計技法

テスト設計技法にはさまざまな種類がありますが、ここでは初心者の方が最初に覚えておくべき2つの技法を紹介します。

同値分割法

同値分割法は、入力値の範囲を同じような特性のグループに分ける技法です。

例えば、年齢入力フォームで「1歳〜120歳」の範囲が有効な場合を考えてみましょう。

すべての値をテストすることは現実的ではありません（1, 2, 3, ... 120）。そこで、同じような特性を持つ値をグループに分けます：

• 有効な値のグループ：1〜120歳
• 小さすぎる値のグループ：0歳以下
• 大きすぎる値のグループ：121歳以上

各グループから代表的な値を1つずつ選んでテストします：

• 有効な値：30歳（グループ内の任意の値）
• 小さすぎる値：-1歳
• 大きすぎる値：121歳

このように、120通りのテストケースを3つに削減できます。同値分割法を使うことで、効率的にテストケースを作成できます。

境界値分析

境界値分析は、範囲の境界（最小値、最大値）をテストする技法です。

経験的に、プログラムのバグは境界付近で発生しやすいことが知られています。そのため、境界値を重点的にテストします。

先ほどの年齢入力の例では、以下の境界値をテストします：

• 下限の境界：0歳、1歳
• 上限の境界：120歳、121歳

境界値分析と同値分割法は、組み合わせて使うことが一般的です：

1. 同値分割法でグループを決める
2. 各グループの境界値を境界値分析で特定する
3. 境界値と代表値の両方をテストケースに含める

この2つの技法を使うことで、効率的かつ効果的なテストケースを作成できます。

テスト設計の実践サンプル

ここまでの内容を踏まえて、実際にテスト設計を行ってみましょう。題材として、Webアプリケーションの「ログイン機能」を取り上げます。

前提：テスト分析でのテスト条件の明確化

テスト設計を始める前に、テスト分析でテスト条件を明確にしておく必要があります。

テスト分析では、マインドマップを使うと、テスト条件を効率的に洗い出せます。

マインドマップとは、思考を視覚化するツールです。中心にテーマを置き、そこから枝を伸ばすように関連する要素を書き出していきます。

テスト分析では、以下のようにマインドマップを活用します：

1. 中心にテスト対象を配置：「ログイン機能」
2. 主要なテスト条件を枝として追加：「認証」「セキュリティ」「ユーザビリティ」など
3. 各テスト条件をさらに詳細化：「認証」→「正常ログイン」「パスワード間違い」など
4. 具体的な確認事項を追加：「正常ログイン」→「正しいID・パスワードでログイン成功」など

マインドマップで明確にしたテスト条件の例：

• 認証の正常動作：正しいID・パスワードでログインできること
• エラー処理：間違ったパスワードの場合、適切にエラーメッセージが表示されること
• 境界条件：パスワードの最大文字数・最小文字数でログインできること
• セキュリティ：パスワードがマスキングされること
• ユーザビリティ：エラーメッセージが分かりやすいこと

このように、テスト分析の段階でマインドマップを使ってテスト条件を明確にします。

ログイン機能のテストケース作成

テスト分析で明確にしたテスト条件をもとに、テスト設計でテストケースを作成します。

以下は、境界値分析を適用してテストケースを具体化した例です：

テストケースには、以下の要素が含まれます：

1. テストID：テストケースを一意に識別するための番号
2. テスト対象：ログイン機能
3. テスト条件：認証の正常動作、エラー処理、境界条件、セキュリティ（テスト分析で明確にされたもの）
4. 事前条件：正しいID・パスワードが登録されている、など
5. 入力値：何をテストするか（太字部分）と、具体的な入力値
6. 期待結果：テストが成功したと判断する基準

テスト設計とテスト実装の違い：この表はテスト設計段階のテストケースです。次の工程であるテスト実装では、このテストケースをもとに、「1. ログイン画面を開く」「2. ユーザIDを入力する」といった実行可能な詳細なテスト手順を作成します。

TC003とTC004は、「パスワードの最大文字数の境界値を確認する」というテスト条件に対して、境界値分析を適用した例です。境界値（20文字、21文字）)を具体的なテストケースにしています。

TC006は、「ユーザIDの入力値」というテスト条件に対して、同値分割法を適用した例です。有効な同値クラス（正しいユーザID）と無効な同値クラス（空欄）を識別し、無効なクラスからテストケースを作成しています。このように、同値分割法と境界値分析を組み合わせることで、効率的かつ効果的なテストケースを作成できます。

このように、テスト分析で明確にしたテスト条件を、テスト設計でテスト技法を使って具体的なテストケースに落とし込んでいきます。

テスト設計の実践ポイント

最後に、テスト設計を実践する際のポイントを、よくある失敗例と正しいアプローチの対比で説明します。

よくある失敗：テスト条件を明確にせずにテストケースを作り始める

初心者によくある失敗が、テスト分析でテスト条件を十分に明確にしないまま、いきなりテストケースを作り始めることです。

例えば、ログイン機能のテスト設計で、こんな進め方をしていませんか?

❌ 悪い例：

「同値分割を使おう。えーと、パスワードを3つのグループに分けて...」

このアプローチの問題点は、「何を確認すべきか」が不明確なまま、テストケースの作成に入っていることです。テスト分析でテスト条件が明確になっていないため、重要な確認事項を見逃してしまいます。

なぜこの失敗が起こるのでしょうか？それは、テスト分析とテスト設計の区別が曖昧になっているからです。

• テスト分析：「何をテストすべきか」を考える工程（テスト条件の明確化）
• テスト設計：「どのようにテストするか」を考える工程（テストケースの作成）

この順序を守らないと、テストの目的が不明確なまま、場当たり的なテストケースを作ることになります。

正しいアプローチ：テスト分析→テスト設計の順で進める

正しいアプローチは、まずテスト分析でテスト条件を明確にし、その後テスト設計でテストケースを作成することです。

✅ 良い例：

【テスト分析】

「ログイン機能で確認すべきことは?
→ 認証の正常動作、パスワード間違い時のエラー、セキュリティ、境界条件...
→ 境界条件では、パスワードの文字数制限を確認する必要がある
→ パスワードの最大文字数は20文字（仕様確認）」

【テスト設計】

「パスワードの最大文字数20文字の境界値をテストしよう
→ 境界値分析を適用
→ テストケース：20文字、21文字

このアプローチの流れを整理すると：

1. テスト分析：仕様を理解し、テスト条件を明確にする（マインドマップが有効）
2. テスト設計：テスト条件に対して適切なテスト技法を選択し、テストケースを作成する
3. テスト実装：テストケースをテスト手順書や自動化スクリプトに落とし込む

「テスト条件の明確化（分析）→テスト技法の適用（設計）」の順序が重要です。テスト条件が明確になっていれば、どのテスト技法を使うべきかも自然と決まります。

段階的にレビューを行う

テストケースが完成してから最後にまとめてレビューするのではなく、各工程の成果物を段階的にレビューすることが重要です。テスト分析の結果（テスト条件）、テスト設計の結果（テストケース）、テスト実装の結果（テスト手順）と、それぞれの段階でレビューを行いましょう。

早い段階で問題を発見・修正することで、手戻りを防ぎ、より効果的なレビューができます。テスト条件とテストケースの対応関係が明確か、テスト技法の適用が適切かなどを、各段階で確認してもらえます。

まとめ

この記事では、テスト設計の基本から実践的なポイントまでを解説しました。

テスト設計は、テスト分析で明確にした「何をテストするか」をもとに、「どのようにテストするか」を具体化する重要な工程です。テスト分析ではテスト条件の明確化や優先付けを行い、テスト設計では同値分割法や境界値分析などのテスト技法を用いてテストケースを作成します。

よくある失敗は、テスト条件を明確にせずにいきなりテストケースを作り始めることです。「テスト分析→テスト設計」の順序で進めることで、効率的なテストを実施し、ソフトウェアの品質を高めることができます。ぜひ実践してみてください。

MagicPod 編集部

テスト自動化の最新トレンドや品質向上のノウハウなど、現場で役立つ情報をお届けします。