要件定義書や仕様書をもとにテストケースを作るとき、確認漏れやケースの重複が起きたり、仕様が曖昧なまま推測で進めてしまったりした経験はありませんか？
テストの手戻りや漏れを防ぐ基本は、テストケースを書き始める前に、仕様から「何をテストするのか」を抽出し、テスト条件と優先順位を整理することです。
確認対象を整理しないまま具体的な手順や期待結果を書き始めてしまうと、似たようなテストが増える一方で、異常系の動作や境界値の確認が抜け落ちやすくなります。
この記事では、テスト分析とテスト設計の違いや具体的な進め方、成果物のまとめ方をわかりやすく解説します。現場で使えるテスト技法や、抜け漏れを防ぐレビューのポイントも紹介しますので、ぜひ参考にしてください。
テスト分析とは
テスト分析とは、具体的なテストケースを作成する前に、要件や仕様から「確認すべき対象」を整理する活動です。
まずは、テスト分析の目的や役割、テスト設計との違いについて見ていきましょう。
1-1. テスト分析の目的と役割
テスト分析の主な目的は、要件定義書や仕様書などの資料（テストベース）を読み解き、「何をテストするか」を明らかにすることです。
具体的には、資料を読むだけでなく、検証すべき機能や特性を「テスト条件」として洗い出し、リスクや影響度に応じて優先順位をつけていきます。
また、仕様を読み解く中で、記述の矛盾や抜け漏れといった仕様書自体の不備に気づくことも珍しくありません。
仕様の曖昧さや課題を早い段階で見つけ、開発者や関係者とすり合わせて解消することも、テスト分析の大切な役割です。
1-2. テスト設計との違い
テスト分析とテスト設計の違いは、焦点を当てる「問い」にあります。テスト分析が「何をテストするか」を明確にするのに対し、テスト設計は「どのようにテストするか」を具体化します。
テスト設計では、分析で整理したテスト条件をもとに、具体的な入力値や操作手順、期待結果を定義したテストケースを作成し、必要なテストデータの要件を整理します。
実務においては、この2つを完全に別の担当者が行ったり、工程を厳密に分けたりする必要はありません。両者を並行して進めたり、行き来しながら反復したりするケースも一般的です。
大切なのは、「確認する対象を決める作業」と「具体的なケースに落とし込む作業」を意識して区別することです。
確認対象を整理しないままケースを作り始めると、似たような操作ばかりが重複し、異常時の確認が抜けるなど手戻りの原因になります。テスト分析は、テストの漏れや重複をなくすための土台となる活動です。
テスト分析の進め方
テスト分析は、以下の3つのステップで進めます。
- テスト対象の仕様を把握する
- テスト条件を洗い出す
- 優先順位と確認範囲を決める
それぞれの進め方を詳しく解説します。
2-1. テスト対象の仕様を把握する
まずはテストの目的や対象範囲を確認し、仕様を正しく把握するための資料（テストベース）をそろえます。
業務フロー全体を確認したいなら要件定義書や業務フロー図、個別の処理なら詳細設計書など、テストの目的に合った資料を選びましょう。
アジャイル開発などでユーザーストーリーを扱う場合は、ストーリーの概要だけでなく「受け入れ基準（Acceptance Criteria）」を精査します。受け入れ基準は機能を受け入れるための必須条件であり、そのままテスト条件のベースになります。
ただし、ストーリーの短い文面だけでは、仕様のすべてが網羅されていないこともあります。
詳細な動作や前提条件については、プロダクトオーナーや開発者と対話し、受け入れ基準を補足しながら「何ができれば正しい動作といえるか」をすり合わせていきましょう。
2-2. テスト条件を洗い出す
仕様の全体像を把握したら、要求・要件に照らして確認すべき機能や特性を「テスト条件」として洗い出します[小友1] 。「システムが意図した通りに動作するか」を確かめる観点を挙げていきましょう。
このとき、正常に動く代表的なケースだけでなく、入力範囲外の値、文字種やフォーマットの制約違反、エラーや例外処理といった異常系の振る舞いも仕様に沿って洗い出すことが重要です。
例えば、「年齢入力」という機能を検証する場合、以下のような観点がテスト条件の候補になります。
- 許容される年齢の範囲内の値を受け付けること
- 許容される範囲外の値を受け付けないこと
- 小数や文字列など、整数以外の値を受け付けないこと
- 入力欄が未入力の場合の扱い
もし仕様書に「未入力時の動作」が書かれていなければ、この段階で推測して「エラーメッセージを表示する」などと勝手に決めてはいけません。
仕様に明記されていない挙動は「仕様の未確定事項・確認事項」としてメモし、確定している条件と明確に分けて管理しましょう。
2-3. 優先順位と確認範囲を決める
洗い出したテスト条件に優先順位を付け、今回のテストで検証する範囲を決定します。
テストにかけられる工数やスケジュールには限りがあるため、すべての条件を均一に確認するのではなく、重点的に確認すべきポイントを絞り込む必要があります。
優先順位は、不具合が起きたときの「影響の大きさ」と、問題が「発生する可能性」というリスクの観点から検討します。
例えば、金銭の計算ミスにつながるような重大な機能は優先度を「高」とし、軽微な表示崩れなどは優先度を下げるといった調整を行います。
どこまでの条件を実際にテストするかという確認範囲は、テストの目的やプロジェクトで事前に合意したカバレッジ基準（網羅対象を定める基準）に照らし合わせて決定しましょう。
テスト分析の成果物とまとめ方
テスト分析で整理した内容は、後続のテスト設計へ正確に引き継ぐために成果物としてまとめます。
ここでは、テスト条件一覧の書き方や不明点の管理方法、テスト設計への連携について解説します。
3-1. テスト条件の記載例と不明点の扱い
テスト分析の主な成果物は、優先順位を付けた「テスト条件一覧」です。
また、仕様書を読み解く中で見つかった曖昧な点や矛盾、記載漏れなどの問題は、欠陥レポートや確認事項リストとして記録・報告します。
「年齢欄は18歳以上65歳以下の整数を受け付ける」という仕様を例に、テスト条件一覧のまとめ方を紹介します。
| 対象機能 | テスト条件 | 優先度 | 根拠となる仕様 | 備考・ステータス |
| 年齢入力 | 18歳以上65歳以下の整数を受け付けること | 高 | 要件定義書 3.1項 | 正常系 |
| 年齢入力 | 18歳未満または66歳以上の値を受け付けないこと | 高 | 要件定義書 3.1項 | 異常系（範囲外） |
| 年齢入力 | 小数や文字列など整数以外の入力を受け付けないこと | 中 | 要件定義書 3.1項 | 異常系（形式不正） |
| 年齢入力 | （未入力時の振る舞い） | ― | 仕様未記載 | 【確認事項】エラーとするか任意とするかを仕様元へ確認中 |
※表内の仕様書名や優先度は説明用のサンプルです。
このように、導き出したテスト条件には必ず根拠となる仕様の箇所を紐付けます。
仕様に書かれていない内容（例：未入力時の振る舞い）は推測で補わず、「確認事項」として分けて記録することがポイントです。
確定した条件と未確定の仕様を明確に区別しておくことで、誤った前提のままテスト設計に進んでしまう手戻りを防げます。
3-2. テスト設計への引き継ぎと仕様の対応付け
テスト条件が整理できたら、テスト設計へと引き継ぎます。
テスト設計では、テスト条件をもとに具体的な入力値や操作手順、期待結果を決めてテストケースを作成します。
例えば、「18歳以上65歳以下の整数を受け付けること」「18歳未満の値を受け付けないこと」という条件に対しては、「17を入力した場合は受け付けない」「18を入力した場合は正常に受け付ける」といった具体的な値と結果を持つケースへ落とし込みます。
このとき重要なのが、根拠となる仕様箇所・テスト条件・テストケースを対応付けて管理すること（トレーサビリティの確保）です。
これらを紐付けておけば、仕様変更が発生した際に見直すべきテストケースをすぐに特定できます。また、要件が漏れなくテストでカバーされているかを後から追跡・確認する際にも役立ちます。
テスト分析で活用できるテスト技法
テスト条件を効率的かつ網羅的に整理するには、テスト技法を活用するのが効果的です。技法はテストケース作成だけでなく、分析の段階でも力を発揮します。
ここでは代表的な技法を2つ紹介します。
4-1. 同値分割法・境界値分析
代表的なテスト技法が「同値分割法」と「境界値分析」です。これらは具体的な入力値を選ぶときだけでなく、「何をテストすべきか」を整理する分析段階でも大いに役立ちます。
- 同値分割法：システムが同じように処理すると想定されるグループ（同値パーティション）に入力値や出力値を分ける手法
- 境界値分析：そのグループの境目（境界値）を確認する手法
例えば、「18歳以上65歳以下の整数」という仕様の場合、同値分割法を使うと「18歳未満（無効）」「18歳以上65歳以下（有効）」「66歳以上（無効）」という3つのグループに整理できます。
さらに境界値分析の観点を加えることで、「17と18」「65と66」というグループの境目で動作が切り替わることを捉え、確認すべき条件としてスムーズに抽出できます。
4-2. HAYST法
入力項目や設定状態、通信環境など、複数の条件が絡み合うシステムでは、すべての組み合わせを総当たりで確認するのは困難です。
こうした複雑な組み合わせを効率的に整理する技法として「HAYST（ヘイスト）法」があります。
HAYST法は、実験計画法で使われる直交表にソフトウェアの機能を割り付け、少ないテスト回数で幅広い機能の組み合わせをテストする技法です（出典：山本訓稔・秋山浩一「直交表を利用したソフトウェアテスト－HAYST法－」JaSST’04、2004年）。
テスト分析において、互いに影響し合うパラメータや状態を洗い出し、どのように組み合わせて確認すべきかを検討する際に有効です。
ただし、技法を使えば自動的に分析が完了するわけではありません。どの条件同士が影響し合っているのかは、担当者が仕様を深く読み解いて見極める必要があります。
HAYST法のような組み合わせ技法は、仕様理解を代行するものではなく、抽出した条件の関係性を効率よく整理するためのツールとして活用しましょう。
テスト分析を行う際のポイント
テスト分析の精度を高め、確認漏れや不要な重複を防ぐために実務で意識したいポイントを2つ解説します。
5-1. 過去のテスト・不具合情報の活用
過去の類似プロジェクトで使ったテスト資料や不具合の記録は、仕様書だけでは見落としやすいテスト条件を探すための有益な手がかりになります。
過去にバグが集中した機能や、例外的な操作によって生じた不具合の事例を参照することで、異常系の動作や境界値周辺の確認漏れをしっかりと補えます。
ただし、過去の情報をそのまま使い回すのは避けましょう。現行システムの仕様が、過去とまったく同じとは限らないためです。
例えば、以前のシステムで「上限65歳」だったものが、改修で「上限70歳」に変更されたとします。このとき、過去のテスト資産をそのまま流用して65歳周辺の条件だけを確認していても、新しく設定された「70歳」の境界値は検証できません。
過去の知見は参考にしつつ、必ず現在の仕様書と照らし合わせて条件を見直すことが不可欠です。
5-2. 仕様との突き合わせとレビュー
テスト条件を洗い出した後は、作成した条件一覧と仕様書を突き合わせて精査します。具体的には、以下の観点で漏れや過不足がないかを確認しましょう。
- 仕様書の要件に対応するテスト条件が抜けていないか
- 各テスト条件に仕様上の根拠があり、推測や思い込みで条件を補っていないか
- 表現が異なるだけで、実質的に同じ内容を確認する条件が重複していないか
また、テスト分析は作成者一人で完結させず、開発者やプロダクトオーナー、他のQA担当者などによるレビューを受けましょう。
仕様の解釈違いや暗黙の前提は、一人ではなかなか気づけないものです。
形式的な承認で終わらせず、「このテスト条件で設計に進んで問題ないか」を関係者間で確認し合うことで、手戻りのリスクを最小限に抑えられます。
まとめ｜テスト分析で「何をテストするか」を明確にする
テスト分析は、仕様書などを読み解き、「何をテストするか」という確認条件と優先順位を明確にする活動です。
具体的なテストケースを作る前に確認対象を整理することで、テストの抜け漏れや不要な重複、仕様の思い込みによる手戻りを未然に防げます。
効果的なテスト分析を行うポイントは、以下の通りです。
- 仕様を把握し、正常系だけでなく異常系のテスト条件も洗い出す
- リスクとカバレッジ基準をもとに優先順位と検証範囲を決める
- 同値分割法や境界値分析などのテスト技法を活用して境界を捉える
- 仕様に書かれていない挙動は推測せず、確認事項として切り離して管理する
- 仕様・テスト条件・テストケースを紐付け、第三者レビューを行う
まずは担当する機能を一つ選び、仕様書をもとに「確認すべき条件」と「仕様上で不明な点」を書き出してみましょう。
テスト条件の整理や確認範囲の決め方にお悩みの場合は、バルテスのテスト計画・テスト設計支援をご活用ください。現状のテストプロセスや網羅度を確認し、製品の目的・リスクに応じた計画と設計の見直しを支援します。
