テストケースの書き方｜他人が迷わず実行できる項目と例

2026 9/03

2026年9月3日 2026年9月3日

「レビューで毎回書き直し」——テストケースが伝わらない本当の理由

テストケースの書き方を調べているあなたは、おそらくレビューで「これでは手順が分からない」「期待結果が曖昧」と差し戻された経験があるのではないでしょうか。技法の記事はたくさんあるのに、いざ書くと同じ指摘を繰り返してしまう。

本記事では、他人が読んで迷わず実行できるテストケースを書くための「記述の作法」を、NG例とOK例を交えて具体的に解説します。

テストケースが伝わらないのは、あなたの能力が低いからではありません。伝わらない原因のほとんどは「記述のルールを知らない」ことにあります。ルールさえ押さえれば、書き直しは確実に減らせます。

よくある差し戻し3パターン

レビューで差し戻される理由は、突き詰めると次の3つにほぼ集約されます。

手順が不明: どの画面で何を操作するのか読み取れず、実行者によって操作が変わる
期待結果が曖昧: 「正常に動作すること」など、合否の判定基準が一意に決まらない
詰め込みすぎ: 1つのケースに複数の確認を盛り込み、どこで失敗したか特定できない

この3つは独立した問題に見えて、根っこは同じです。いずれも「書いた本人にしか分からない」状態になっているのです。

なお、この3つにはそれぞれ対策があります。「詰め込みすぎ」は本記事の〈1ケースの粒度〉、「期待結果が曖昧」は〈期待結果の書き方〉、「手順が不明」は〈事前条件と手順の書き方〉の章で詳しく扱います。差し戻された理由に心当たりがあれば、まずその章から読んでも構いません。

技法の記事を読んでも書けない理由

「テストケース書き方」で検索すると、同値分割や境界値分析といった技法の解説が数多く出てきます。これらは、確認すべき事柄（テスト条件）から、実際に投入する入力値やテストケースを体系的に導くための技術です。

しかし現場でつまずくのは、その一歩先です。導き出した確認内容を、事前条件・手順・期待結果という文章と項目にどう落とし込むか——この記述レベルの壁は、技法記事だけでは埋まりません。

技法は「何をテストするか」を教えてくれますが、「どう書けば他人に伝わるか」は別のスキルなのです。

この記事で目指すゴール

本記事のゴールは、次の状態になることです。

事前条件・手順・期待結果を適切な粒度と具体度で書き分けられる
曖昧な期待結果をなくし、合否が一意に決まる書き方が身につく
レビューで指摘される前に、自分でNGな書き方に気づける
Excelやツールでチームが再利用しやすいフォーマットを整えられる

順を追って読めば、我流から抜け出して「伝わるテストケース」を書けるようになります。

良いテストケースの条件——「他人が読んで同じ結果になる」

まず、目指すべき「良いテストケース」の姿を言語化しておきましょう。基準が曖昧なままでは、自分の書いたケースの良し悪しを判断できません。

良いテストケースが満たす4条件

良いテストケースは、次の4つの条件を満たしています。

条件	意味	満たされないと
再現可能	誰が実行しても同じ手順・同じ状態を作れる	実行者によって操作がブレる
合否が一意	期待結果が具体的で、合否の判定に迷わない	人によって合否判定が変わる
独立している	他のケースの実行結果に依存しない	失敗の原因を特定できない
要件と紐づく	どの要件・観点を確認しているか追跡できる	テストの網羅性を検証できない

この4条件のうち、レビューで最も指摘されるのが「再現可能」と「合否が一意」の欠如です。逆に言えば、この2つを意識するだけで差し戻しは大きく減ります。

「自分が分かる」と「他人が分かる」は違う

書いた本人は、対象の仕様も操作の流れも頭に入っています。だから「ログインして検索する」と書けば十分に思えます。

しかし、仕様を知らない実行者にとっては、どのIDでログインするのか、何を検索するのか、まったく分かりません。

テストケースは、仕様を知らない他人が読んでも同じ結果に到達できることを前提に書きます。この視点の切り替えが、伝わる記述の出発点です。

用語の整理（テストケース／テスト手順／テスト条件）

書き方の話に入る前に、混同しやすい用語を整理します。

テスト条件: テスト対象のうち「確認すべき事柄」（例: パスワードの文字数チェック）
テストケース: テスト条件を検証するための、事前条件・入力・手順・期待結果の一式
テスト手順: テストケース内で実際に操作する一連のステップ（本記事ではこの意味で使います）
テストシナリオ: 複数のテストケースを、実際の業務フローに沿ってつないだ一連の流れ（例: 会員登録→ログイン→商品購入）。1つの機能を狙うケースとは目的が異なります

なお、本記事でいう「観点」は、この「テスト条件（確認すべき事柄）」を実務でくだいた言い方だと捉えて差し支えありません。「このケースで確かめたいこと」を指す点で、両者はほぼ重なります。

用語の定義は、テスト技術者資格制度であるJSTQBの用語集・シラバスで確認できます。なお、より厳密なJSTQBの用語では「テスト手順」は複数のテストケースを実行する順序やセットアップまで含む場合があるため、チームでは「ケース内の操作ステップ」を指すのか「ケース群の実行順」を指すのかを明確にしておくと誤解を避けられます。まずは共通の定義を土台にしておきましょう。

テストケースの書き方の基本——最低限そろえる構成項目

ここからが本題です。最初の一歩は、どんな項目をそろえるかを決めることです。項目が欠けていると、どれだけ丁寧に書いても情報が抜け落ちます。

必須項目と任意項目の一覧

一般的なテストケースに含める項目を、役割と記入例とともに整理します。

項目	区分	役割	記入例
テストID	必須	ケースを一意に識別する	TC-LOGIN-001
目的・観点	必須	何を確認するケースか	パスワード文字数の下限チェック
事前条件	必須	実行前に整えておく状態	未ログイン状態でログイン画面を表示
手順	必須	操作の順序	1. IDに「user01」を入力 …
入力データ	必須	手順で使う具体値	パスワード「Pass123」（7文字）
期待結果	必須	合否を判定する基準	「8文字以上で入力してください」を表示
優先度	任意	実行順やリスクの目安	高
実行結果欄	任意	実行時の合否・実測値を記録	（実行時に記入）

目的・観点、事前条件、手順、入力データ、期待結果の5項目は、どんなプロジェクトでも省略してはいけない骨格です。

項目間の関係（観点→手順→期待結果の流れ）

これらの項目はバラバラに存在するのではなく、1本の線でつながっています。

観点が「何を確かめたいか」を決める
その観点を確かめるために必要な事前条件と手順・入力データを組む
手順を実行した結果、こうなるはず、というのが期待結果

つまり観点が出発点で、期待結果がゴールです。観点が曖昧だと、手順も期待結果もぼやけます。「このケースで一番確かめたいことは何か」を一文で言えるかを、まず自問してください。

プロジェクトで項目を増減する判断基準

項目は多ければ良いというものではありません。埋めるコストと、得られる情報のバランスで決めます。

追加を検討: 実行環境が複数ある場合の「環境」列、不具合追跡のための「関連チケット」列
省略を検討: 全ケース同一で自明な項目、運用で誰も参照しない項目

判断基準はシンプルで、「その列がないと実行者や後の担当者が困るか」です。困らないなら省き、困るなら残す。この観点で自チームのフォーマットを見直しましょう。

完成した1ケースの全体像

ここまでの項目を1つのケースに落とし込むと、次のようになります。パスワード文字数の下限チェックを例に、全項目を埋めた完成形を見てください。

項目	記入内容
テストID	TC-REGIST-014
目的・観点	パスワード文字数の下限（8文字未満）を弾けること
事前条件	未ログイン状態で会員登録画面を表示している。同一メールアドレスの登録は未実施
手順	1. メールアドレス欄に「test@example.com」を入力する 2. パスワード欄に「Pass123」（7文字）を入力する 3.「登録する」ボタンを押す
入力データ	パスワード「Pass123」（7文字・下限未満）
期待結果	パスワード欄の直下に「パスワードは8文字以上で入力してください」と赤字で表示され、登録は完了せず、入力したメールアドレスは保持される
優先度	高

断片で覚えた型も、こうして1枚に並べると「観点→事前条件→手順→入力→期待結果」が1本の線でつながっていることが実感できます。まずはこの完成形を手元のケース1件に当てはめ、埋まっていない項目がないかを確認してみてください。

1ケースの粒度——詰め込みすぎず、細かすぎず

項目がそろっても、1ケースにどこまで盛り込むかで悩む人は多いはずです。粒度は、テストケース作成で最もセンスを問われる部分です。

基本原則は「1ケース＝1つの確認内容」

粒度の基本原則は明確です。1つのテストケースで確認するのは、原則として1つの観点だけにします。観点が1つに絞れていれば、期待結果も自ずと1つに収束します。

こうしておくと、そのケースが失敗したときに「何が壊れているか」が即座に分かります。逆に複数の確認を混ぜると、失敗の原因究明に時間がかかります。

詰め込みすぎの例と弊害

たとえば、ログイン機能で次のように書いたとします。

> 手順: 正しいID・パスワードでログインし、検索欄に「東京」と入力して検索し、結果一覧から1件目を開き、詳細画面の内容を確認する

これは「ログイン」「検索」「詳細表示」という3つの確認を1ケースに詰め込んでいます。もし検索でエラーが出たら、このケースは「失敗」ですが、ログインは成功していたのか、詳細表示は問題ないのか、記録には残りません。

弊害は明確です。どのステップで落ちたかが特定できず、再実行や原因調査に余計な手間がかかります。

細かすぎ・分割しすぎの弊害

逆に、細かくしすぎるのも問題です。「IDを入力する」「パスワードを入力する」「ログインボタンを押す」をそれぞれ別ケースにすると、ケース数が爆発し、管理コストが跳ね上がります。

また、意味のある1つの機能確認が複数ケースに分断され、「結局この機能は正しく動くのか」が一覧から読み取りにくくなります。

粒度は「細かければ丁寧」ではありません。意味の単位で区切るのが正解です。

分割すべきか迷ったときの判断ポイント

迷ったときは、次の3タイプを見比べて自分のケースがどれに近いか判断してください。

タイプ	特徴	判定
詰め込み型	複数の観点を1ケースに混在	観点ごとに分割する
適正	1観点を、意味のある操作単位で確認	この粒度を維持
過分割	1操作ごとにケースを分断	意味の単位でまとめ直す

判断の軸は「失敗したときに原因を1つに絞れるか」と「1つの意味ある確認になっているか」の2点です。この2軸で見れば、多くの迷いは解消します。

テスト観点の切り出しそのもので迷う場合は、テスト観点の洗い出し手順を確認すると、粒度を決める前段の整理がしやすくなります。

例外：あえて一連の流れを1ケースにするシナリオテスト

「1ケース＝1観点」は、あくまで機能単位の確認における原則です。実際の利用シーンに沿って複数機能を通しで確認する「シナリオテスト」や、リリース前の受け入れ確認では、あえて「ログイン→検索→予約→確定」のような一連の流れを1ケースにまとめることがあります。

この場合の狙いは個々の機能ではなく「業務の流れが最後まで破綻なくつながるか」であり、それ自体が1つの観点だからです。ただしその場合も、各ステップに対応する期待結果を段階的に書き、どのステップで失敗したかが記録に残るようにしておくことが前提です。

前述の「ログインして検索して詳細を開く」を1ケースにするのが問題なのは、業務フローの確認を狙ったわけではなく、機能単位の確認を無自覚に混ぜているからです。「何を1つの観点とみなすか」を意識すれば、粒度の迷いは減ります。

期待結果の書き方——「正常に動作する」をやめる

レビューで指摘が集中しやすいのが、期待結果の曖昧さです。テストケースの書き方の中でも、ここが合否を左右する心臓部です。

なぜ「正常に動作する」はNGか

「正常に動作すること」「問題なく表示されること」——こうした期待結果は、一見もっともらしく見えて、実は何も言っていません。

「正常」の基準が書かれていないため、実行者が自分の解釈で合否を判断してしまいます。結果として、ある人は合格、別の人は不合格と、判定がブレます。

期待結果は「実行者が自分で解釈する余地をゼロにする」つもりで書きます。

一意に書く型（表示・値・状態遷移・保存内容・メッセージ文言を具体化）

期待結果を一意にするには、次の観点を具体的に書き切ります。

表示: どの画面に、何が表示されるか
値: 表示される数値・件数・金額などの具体値
状態遷移: 操作後に画面や対象がどの状態に変わるか
保存内容: DBやファイルに何がどう記録されるか
メッセージ文言: エラーや完了メッセージの正確な文字列

このうち一つでも該当するものを、あいまい語なしで書けば、合否は自然に一意になります。

慣れないうちは、次の文型に当てはめると一意な期待結果を書きやすくなります。

> 「〈どこに〉〈何が／どんな値が〉〈どうなる〉、かつ〈対象の状態〉が〈どうなる〉」

たとえば「トップ画面に『user01さん』が表示され、ログイン状態が保持される」。「表示される」で止めず、操作対象の状態変化まで含めるのがコツです。この型に沿えば、書き漏らしが自然に減ります。

NG例→OK例のビフォーアフター

具体的に、身近な題材で対比してみましょう。

場面	NG例	OK例
ログイン成功	正常にログインできる	ログイン後、トップ画面へ遷移し、右上に「user01さん」と表示される
検索	検索結果が表示される	「東京」に一致する店舗が3件、登録順に一覧表示される
入力保存	正しく保存される	保存後、一覧に新規行が1件追加され、氏名列に「山田太郎」が表示される
パスワード文字数	エラーになる	「パスワードは8文字以上で入力してください」と赤字で表示され、登録は完了しない

OK例はどれも、実行者が画面を見て「書いてある通りか」を照合するだけで合否が決まります。これが一意な期待結果です。

書くときのコツは、頭の中で「実行者が画面を見ながら答え合わせをする様子」を想像することです。実行者が「これは合格でいいのかな」と一瞬でも迷うなら、その期待結果はまだ具体化が足りません。

特に件数や表示順、ソートの条件は書き漏らしがちです。「3件表示される」だけでなく「登録順に」「新しい順に」まで書くと、並び順のバグも拾えます。金額や日付のフォーマットも、「1,000円」「2026/08/27」のように表示形式まで指定しておくと安心です。

エラー系・異常系の期待結果の書き方

正常系だけでなく、エラー系こそ具体的に書く必要があります。「エラーになる」では、どんなエラーが正解か分かりません。

メッセージ文言を正確に書く（表記ゆれ・句読点まで仕様通りに）
登録や更新が行われないことも期待結果に含める
入力値が保持されるのかクリアされるのか、画面の挙動も明記する

たとえば「未入力でボタンを押すと『メールアドレスを入力してください』と表示され、他の入力欄の値は保持される」まで書けば、実行者は迷いません。異常系は「何が起きないか」も期待結果である点を忘れないでください。

もう一つ、異常系でありがちなのが「エラーメッセージの表示位置や見た目」の書き漏れです。同じ文言でも、画面上部にまとめて出るのか、入力欄の直下に出るのかは仕様として区別されることがあります。「該当の入力欄の下に赤字で表示される」のように、位置と装飾まで書けると、より厳密なチェックになります。

複数のエラーが同時に起こり得る場合も要注意です。メールアドレスとパスワードの両方が未入力なら、両方のメッセージが出るのか、片方だけなのか。期待結果に「2つのエラーメッセージが同時に表示される」と明記しておけば、実装のバグを見逃しません。

正常系・異常系・境界のバランスを取る

1つの機能を確認するとき、正常系だけを並べても品質は保証できません。次の3種類を意識してそろえると、抜けが減ります。

正常系: 想定どおりの入力で、期待どおり動くことを確認する（例: 正しいID・パスワードでログインできる）
異常系: 想定外・不正な入力で、正しく弾かれることを確認する（例: 未入力、文字数超過、禁止文字）
境界値: 仕様の境目（上限・下限）付近で、判定が切り替わることを確認する（例: 8文字ちょうど／7文字）

経験則として、バグは正常系より異常系・境界に潜みがちです。正常系ばかり厚くなっていたら、異常系と境界が手薄になっていないかを疑ってください。1つの入力項目につき「正しい値・不正な値・境界の値」の3方向をそろえるだけでも、網羅性は大きく上がります。

事前条件と手順の書き方——他人が同じ状態で再現できるように

期待結果が一意でも、実行前の状態や手順がブレれば結果は再現しません。事前条件と手順は、再現性を支える土台です。

事前条件に書くこと

事前条件には、手順を始める前に整えておくべき状態をすべて書きます。

ログイン状態: 誰として、どの権限でログインしているか（または未ログイン）
データ: 対象データが存在するか、件数や中身はどうか
権限: 実行ユーザーのロール・アクセス権
環境: 対象のブラウザ・OS・テスト環境
前提設定: 機能フラグや設定値の状態

「この状態から始めれば誰でも同じスタート地点に立てる」まで書き切るのが事前条件の役割です。

見落としやすいのが、テストの「順番」に依存した前提です。前のケースで登録したデータが残っている状態を暗黙の前提にしていると、そのケースを単独で実行したときに再現しません。事前条件は、他のケースを実行していなくても成り立つように書くのが原則です。

たとえば「会員が3件登録済み」という前提が必要なら、「テスト用アカウントA・B・Cが登録済みであること」と、必要なデータを名指しで書きます。こうしておけば、実行者はデータの有無を自分で判断でき、順番に縛られずに実行できます。

忘れられがちな「事後条件」

事前条件と並んで、本来テストケースの構成要素に含まれるのが「事後条件」です。これは、ケースを実行し終えた後に対象がどういう状態になっているべきか、次のテストのために何を後片付けすべきかを示します。

たとえば「テストで登録した会員データを削除し、初期状態に戻す」「発行したトークンを無効化する」といった記述です。事後条件を書いておくと、テストを繰り返し実行してもデータが積み上がって結果がブレる、といった事故を防げます。

毎回自明な場合は省略して構いませんが、データを作成・変更するケースでは明記を検討してください。

手順の粒度（1ステップ1操作・主語と操作対象を明確に）

手順は「1ステップ＝1操作」を基本にします。1つのステップに複数の操作を詰めると、どこで失敗したかが曖昧になります。

また、各ステップは「何を」「どうする」を明確にします。「入力する」だけでなく「メールアドレス欄に『test@example.com』を入力する」と、操作対象と操作内容をセットで書きます。

手順の言葉づかい（曖昧語を避ける・画面名/ボタン名を正確に）

手順の言葉づかいは、再現性を大きく左右します。曖昧語を排し、画面やボタンの名称を仕様通りに書きます。

NG例	問題点	OK例
適当に検索する	入力値が不定で再現できない	検索欄に「東京」と入力し、「検索」ボタンを押す
ログインする	どのIDか不明	IDに「user01」、パスワードに「Pass1234」を入力し「ログイン」を押す
画面を確認する	何を見るか不明	会員一覧画面が表示されることを確認する
ボタンを押す	どのボタンか不明	画面下部の「登録する」ボタンを押す

「適当に」「正しく」「きちんと」といった副詞は、テスト手順の敵だと覚えておいてください。

入力データの示し方（具体値・境界値・データ準備の明記）

入力データは、必ず具体値で示します。「正しいパスワード」ではなく「Pass1234」のように、そのまま入力できる値を書きます。

境界値を狙う場合は、なぜその値かも意識します。文字数チェックなら「7文字（下限未満）」「8文字（下限）」のように、境界を挟む値を選びます。

入力値を体系的に洗い出すには、技法が役立ちます。無効・有効のグループから代表値を選ぶ同値分割法で入力値を洗い出す手順を見ると、値の選び方に根拠を持たせられます。さらに境界付近の不具合を狙うなら、境界値分析でテストケースを作る具体例を見ると、具体値の決め方が明確になります。

なお、特別なデータ準備が必要な場合は、その手順も事前条件か手順の冒頭に明記します。「対象データがある前提」で書くと、実行者がつまずきます。

レビューで指摘されないためのセルフチェック観点

書き方の型が分かったら、提出前に自分で点検する習慣をつけましょう。セルフチェックができれば、レビューの往復回数が減ります。

レビューで頻出する指摘と対応

まず、どんな指摘が多いかを知っておくと、先回りできます。

頻出指摘	原因	対応
手順が分からない	操作対象・入力値が不明確	画面名・ボタン名・具体値を明記
期待結果が曖昧	「正常に」等のあいまい語	表示・値・文言を具体化
詰め込みすぎ	複数観点の混在	観点ごとに分割
事前条件が不足	実行前の状態が未記載	ログイン・データ・権限を追記
観点が不明	目的列が空	一文で確認内容を書く

提出前セルフチェックリスト

提出前に、次のリストをそのまま使って点検してください。

[ ] このケースで確認したい観点を一文で言えるか
[ ] 事前条件だけで、誰でも同じ状態を作れるか
[ ] 手順は1ステップ1操作で、操作対象と入力値が具体的か
[ ] 「適当に」「正しく」などの曖昧語が残っていないか
[ ] 期待結果は、実行者が解釈せず合否を判定できるか
[ ] エラー系で「何が起きないか」まで書けているか
[ ] 1ケースに観点を詰め込みすぎていないか

要件・観点とのトレーサビリティ

最後に、そのケースがどの要件・観点に対応するかを追えるようにしておきます。目的列や要件IDを紐づけておくと、抜け漏れの確認や仕様変更時の影響調査が容易になります。

どの要件を確認しているか追えないケースは、テストの網羅性そのものを証明できません。トレーサビリティは、地味ですが品質を語るうえで欠かせない土台です。

レビューは、単なる粗探しではなく品質を作り込む工程です。ソフトウェア開発の品質に関する定量的な傾向は、IPAのソフトウェア開発分析データ集などでも継続的に調査されています。早い工程での作り込みと点検が、後工程の手戻りを抑える一般的な傾向は、こうした調査からも読み取れます。

Excel・管理ツールでのテストケースの書き方と再利用

最後に、Excelや管理ツールでのケース記述と、再利用しやすい整え方を押さえましょう。フォーマットが整うと、チーム全体の書きぶりがそろいます。

Excelフォーマットの基本列設計

Excelで作る場合の、推奨する基本列構成です。

列	内容	補足
ID	テストID	命名規則で機能・連番を表す
観点	確認したいこと	一文で書く
事前条件	実行前の状態	ログイン・データ・権限
手順	操作ステップ	セル内で番号付き
入力	入力データ	具体値・境界値
期待結果	合否基準	表示・値・文言を具体化
結果	実行時の合否	OK/NGや実測値
備考	補足・関連情報	関連チケット等