2026年10月8日
テストケースについて
システムテスト 2026年10月29日
#テストケース
1. テストケースとは
テストケースとは、テスト実行するために必要な「事前の条件・入力値・実行手順・期待される結果」を一つに整理しまとめたものです。
これを日常生活に例えるなら、「料理のレシピ」と言えます。
「美味しいカレーを作る」という目的（テスト観点）に対し、「どのメーカーのルーを使い（実行条件）」「ジャガイモを何センチ角に切り（入力値）」「何分煮込むか（実行手順）」が具体的に書かれていれば、誰が作っても同じ味（期待結果）になります。
2. 必須項目と注意したい誤解
優れたテストケースには、情報の「漏れ」や「曖昧さ」がありません。以下の5項目を軸に構成するのが標準的です。
| 項目名 | 内容のポイント |
| テスト対象 | どの機能や画面をテストするのか。大・中・小項目で階層化すると管理しやすい。 |
| テスト観点 | 「何を確認したいのか（意図）」を明記。例：重複登録時のエラー挙動など。 |
| 実行条件 | 使用するデータやアカウント、OS環境など。前提となる設定を漏れなく書く。 |
| 実行手順 | 操作をステップごとに記述。ボタンの名称やURLなど、客観的な情報を入れる。 |
| 期待結果 | 「OK」と判断する基準。画面遷移、メッセージ内容、DBの更新状態など。 |
【要注意】よくある誤解の例 ：
テスト対象
- 内容のポイント：ソフトウェアのどの機能、どの画面、どのデバイスを対象にするかを明確にします。
- よくある誤解の例 ：作成者は「ログイン機能（PC・スマホ両方）」のつもりで書いたが、実施者は「（自分が今使っている）PC版のChrome」だけでテストを済ませてしまった。
- 結果 ：スマホ固有のレイアウト崩れや、Safariブラウザだけで発生するスクリプトエラーを見逃し、リリース後にユーザーからクレームが届く。
テスト観点
- 内容のポイント：「何を確認するためのテストか」という目的（着眼点）を示します。
- よくある誤解の例 ：作成者は「異常系のエラーメッセージが仕様書通りか」を確認してほしかったが、項目に「エラー確認」とだけ書いたため、実施者は「エラーが出て画面が固まらなければOK」と解釈した。
- 結果 ：エラー自体は表示されたものの、文言が古いままだったり、全く関係のないエラーコードが表示されていたりすることに気づけない。
実行条件
- 内容のポイント：テストを開始する前の前提状態（使用データ、アカウント権限、設定値など）を定義します。
- よくある誤解の例 ：作成者は「退会済みユーザー」での挙動を見たいと考え「特定のステータスのユーザー」と書いたが、実施者は「昨日作ったテスト用ユーザー」をそのまま使い回した。
- 結果 ：前提条件が異なるため、本来エラーになるべき操作が成功してしまい、テストの目的が果たされない。
実行手順
- 内容のポイント：テスターが迷わず再現できるよう、具体的な操作ステップを記述します。
- よくある誤解の例 ：作成者は「保存ボタンを1回押して完了を待つ」ことを想定していたが、実施者は「反応が遅かったのでボタンを連打」してみた。
- 結果 ：ボタン連打による「二重送信」という別のバグが見つかることもあるが、基本的には「手順外の操作」によりデータが壊れ、本来確認すべき項目が判定不能になる。
期待結果（表示・挙動）
- 内容のポイント：「何をもって合格とするか」の客観的な判断基準です。
- よくある誤解の例 ：作成者は「デザイン通りに表示されること」を期待したが、実施者は「文字化けしておらず、なんとなくボタンが配置されているからOK」と判断した。
- 結果 ：1ピクセルのズレ、フォントの違い、カラーコードの間違いなど、UI/UXに関わる不備がすべてスルーされてしまう。
期待結果（データの裏側）
- 内容のポイント：画面上の変化だけでなく、データベース（DB）やサーバー内の状態が正しく更新されたかを確認します。
- よくある誤解の例 ：作成者は「DBからデータが物理削除されること」を意図したが、実施者は「画面上の一覧から消えたこと」だけでOKを出した。
- 結果 ：画面上は見えなくなっているが、DBには不要なデータが残り続け、将来的にシステムの動作が重くなったり、統計データに不整合が出たりする。
上の図のように、テスト作成者にとっては複雑な経路を綿密に動くイメージをもって作成したテストケースも具体性を書いていると、テスト実施者にとっては最短距離でゴールに向うことができる道に思える場合が多々ある。
3. 「ハイレベル」と「ローレベル」の使い分け
テストケースには、詳細度の違いによって2つの種類があります。これらを状況に応じて使い分けることが、効率的なテストの鍵となります。
ハイレベル vs ローレベル 比較表
| 比較項目 | ハイレベルテストケース | ローレベルテストケース |
| 別名 | 論理テストケース | 具体的テストケース |
| 内容の濃さ | 「何を確認するか」という抽象的な条件。 | 「どう操作し、どの値を入れるか」の詳細。 |
| メリット | 仕様変更に強く、メンテナンスが楽。 | 誰でも実行でき、結果にバラつきが出ない。 |
| デメリット | 実施者のスキルによってテストの質が変わる。 | 作成に時間がかかり、仕様変更時の修正が大変。 |
| 最適な場面 | 開発初期のレビュー、熟練者が行うテスト。 | 大規模な検証、外部委託、自動化のベース。 |
Tips: 入力値の選び方全てのパターンを試すのは現実的ではありません。境界値分析（範囲の境目）やエラー推測を駆使して、最もバグが出やすい「急所」を狙い撃ちするのが効率的です。
4. 品質の高いテストケースを作る「4つの鉄則」
作成者と実施者の「橋渡し」をスムーズにするためのルールです。
- 「具体的」は正義（再現性の確保）
「長い文字列」ではなく「全角50文字」。「しばらく待つ」ではなく「5秒待つ」。このように数値化できるものはすべて数値化することで具体的に記載すると再現性が高まります。 - 期待結果に「形容詞」を使わない
「正しく」「適切に」「速やかに」といった言葉は人によって解釈が異なります。「○○というメッセージが表示される」「3秒以内に画面遷移する」と、事実だけを書きましょう。 - トレーサビリティ（追跡可能性）を意識する
「このテストは要件定義書の第○章に対応している」という紐付けを行います。仕様変更があった際、「どのテストケースを直すべきか」が秒速で判断できるようになります。 - 「前提」と「手順」を分ける
料理で言えば「オーブンを180℃に予熱しておく」のが前提条件、「生地を流し込む」のが手順です。ここが混ざると、実行者は準備不足で作業を中断せざるを得なくなります。実行手順と前提条件は明確に区別できるように記載しましょう。
まとめ
テストケースを丁寧に作り込むことは、単なる確認作業の効率化だけではありません。作成者が込めた「品質へのこだわり」を実施者に正しく伝え、チーム一丸となって不具合をブロックするためのコミュニケーションツールなのです。
