テストケースを考える力を身につける方法とは？IT初心者向けにテスト観点の作り方を解説

結論からいうと、テストケースを考える力を身につけるには、「正常に動くか」だけではなく、「どんな条件なら壊れるか」「境目ではどうなるか」「利用者が想定外の操作をしたらどうなるか」を考える習慣が必要です。

テストケース作成が苦手な初心者は、仕様書を読んでそのまま正常系だけを書いてしまいがちです。

しかし実際のIT現場では、正常な入力よりも、空欄、上限値、権限不足、通信失敗、データ不存在といった条件で不具合が見つかることがあります。

テストケースを考える力とは、単にテスト項目をたくさん作る能力ではありません。仕様やシステムを見て「どこに問題が入りそうか」を予測する力です。

テストケースとは何か

テストケースとは、システムやプログラムが期待どおりに動作するか確認するために、条件、操作、入力値、期待結果などを整理したものです。

たとえば「年齢は18歳以上100歳以下を入力できる」という仕様なら、20歳を入力して登録できることだけでは十分ではありません。

• 18を入力した場合
• 100を入力した場合
• 17を入力した場合
• 101を入力した場合
• 空欄の場合
• 文字を入力した場合

このように、仕様から確認すべき条件を洗い出していきます。

テストケースとテスト観点の違い

初心者が最初に理解しておきたいのが、テスト観点とテストケースの違いです。

項目	意味	例
テスト観点	何を確認するかという視点	入力値の上限・下限を確認する
テストケース	具体的な条件と操作	100を入力して登録できることを確認する

テストケースをいきなり大量に書こうとすると、抜けが発生しやすくなります。

最初に観点を洗い出し、そのあと具体的なケースへ落とし込むと整理しやすくなります。

なぜテストケースを考える力が重要なのか

IT現場では、テスト仕様書が用意されている場合でも、書かれた内容を実行するだけでは十分でないことがあります。

仕様変更が入ったときや、不具合修正後の確認では、自分で影響範囲を考えてテストする場面があります。

また、社内SEや運用保守でも同じです。

たとえば「共有フォルダにアクセスできない」という問い合わせがあった場合、単にフォルダを開くだけでは原因を特定できません。

• 別のユーザーなら開けるか
• 別のPCなら開けるか
• IPアドレス指定なら開けるか
• 名前指定だけ失敗するか
• 読み取りだけできるか
• 書き込みだけできないか

こうした確認も、本質的にはテストケースを考える力と同じです。

最初に身につけたい「正常系・異常系」の考え方

テストケースを考えるときは、まず正常系と異常系に分けます。

正常系とは

仕様どおりの入力や操作を行ったとき、期待する結果になることを確認するテストです。

たとえばログイン画面なら、正しいユーザーIDとパスワードを入力してログインできることを確認します。

異常系とは

入力ミスや通信障害など、通常とは異なる条件で適切に処理されるか確認します。

• パスワードが間違っている
• ユーザーIDが存在しない
• 入力欄が空欄
• アカウントが無効
• ネットワークに接続できない

正常系が通ることだけでなく、失敗すべき条件で正しく失敗することも品質です。

テストケースを考える基本の順番

初心者は、次の順番で考えると抜けを減らしやすくなります。

1. 仕様を確認する
2. 正常な動作を整理する
3. 入力項目を洗い出す
4. 境界値を探す
5. 異常な入力を考える
6. データがない場合を考える
7. 権限がない場合を考える
8. 外部システムが失敗する場合を考える
9. 操作順序を変えた場合を考える
10. 変更による影響範囲を確認する

考え方1．境界値を探す

テストケースを考えるうえで非常に重要なのが、境界値テストです。

境界値とは、条件の境目となる値です。

たとえば「1～100まで入力できる」という仕様なら、次の値を確認します。

• 0
• 1
• 2
• 99
• 100
• 101

すべての数値を試さなくても、境界付近を重点的に確認することで条件式の間違いを発見しやすくなります。

たとえば本来「100以下」とするところを「100未満」と実装すると、100だけ登録できません。

考え方2．「空・なし・0」を試す

テストケースを考えるときに便利なのが、「空だったらどうなるか」という視点です。

• 入力欄が空欄
• 検索結果が0件
• ファイルが存在しない
• 対象ユーザーが存在しない
• 取得したデータがNULL
• リストが0件

開発中は必要なデータがそろった状態で確認するため、「存在しないケース」は見落とされやすいポイントです。

考え方3．入力値を変形させる

文字入力では、単純に正しい文字列と間違った文字列だけを見るのではなく、さまざまな形を考えます。

• 全角と半角
• 大文字と小文字
• 前後のスペース
• 非常に長い文字列
• 記号
• 改行を含む文字列
• 数字だけ
• 日本語
• 英数字

たとえば社員番号として「00123」と「123」を同じものとして扱うのかも、仕様によって重要になります。

考え方4．権限を変える

業務システムでは、ログインユーザーによってできる操作が違うことがあります。

そのため、権限もテスト観点になります。

• 管理者ユーザー
• 一般ユーザー
• 閲覧専用ユーザー
• 無効化されたユーザー
• 対象部署に所属していないユーザー

Active Directoryや社内システムでは、グループ所属によって権限が変わることもあります。

「正しいユーザーでできる」だけでなく「権限のないユーザーではできない」ことも確認します。

考え方5．外部システムが止まった場合を考える

業務システムは、データベースやAPIなど別の仕組みに依存することがあります。

• データベースに接続できない
• APIからエラーが返る
• 通信がタイムアウトする
• DNSで名前解決できない
• ファイルサーバーにアクセスできない
• Active Directoryへ接続できない

外部サービスが正常である前提だけでテストすると、障害発生時の問題を見逃します。

本番環境を実際に停止させる必要はありません。テスト環境やモックなど、安全な方法で確認します。

考え方6．操作する順番を変える

画面テストでは、入力値だけでなく操作順序も重要です。

たとえば登録画面なら次のような操作があります。

• 入力してから登録する
• 何も入力せず登録する
• 入力後にキャンセルする
• 登録ボタンを連続で押す
• 途中でブラウザの戻るボタンを押す
• 入力途中で画面を再読み込みする

利用者は開発者が想定した順番で操作するとは限りません。

考え方7．時間に関係する条件を見る

日時を扱う機能では、時間も重要なテスト観点です。

• 月末
• 年末年始
• うるう年
• 日付変更直前・直後
• 有効期限当日
• 有効期限の前日・翌日

「30日経過したら無効」のような仕様では、29日、30日、31日など境界を確認します。

考え方8．組み合わせを考える

システムでは、1つの条件だけでなく複数条件の組み合わせによって結果が変わることがあります。

たとえば「管理者かつ有効ユーザーなら削除できる」という仕様なら、次の組み合わせがあります。

管理者	有効ユーザー	期待結果
はい	はい	削除できる
はい	いいえ	仕様に従う
いいえ	はい	削除できない
いいえ	いいえ	削除できない

条件が増えると組み合わせも増えるため、重要な組み合わせを選んで確認します。

テストケースを作るときの実務的な項目

現場のテスト仕様書では、次のような項目を記録することがあります。

項目	内容
テスト番号	ケースを識別する番号
テスト内容	何を確認するか
事前条件	テスト開始前の状態
入力値	使用するデータ
操作手順	実施する操作
期待結果	正しい結果
実施結果	実際の結果
証跡	画面キャプチャやログなど

期待結果は「正常になること」のように曖昧にせず、具体的に書くことが重要です。

悪い期待結果と良い期待結果

テストケースでは期待結果の書き方も重要です。

悪い例は「正常に登録できること」です。

これだけでは、何をもって正常と判断するのか分かりません。

より具体的には、「完了メッセージが表示され、一覧画面に社員番号12345のユーザーが1件追加されること」のように書きます。

確認者が変わっても同じ判断ができる状態が理想です。

実際のIT現場でのテストケース例

共有フォルダへのアクセス機能を確認するとします。

単に「共有フォルダを開けること」だけではなく、次のような観点があります。

• 権限のあるユーザーがアクセスできる
• 権限のないユーザーがアクセスできない
• 読み取り専用ユーザーがファイルを閲覧できる
• 読み取り専用ユーザーがファイルを更新できない
• サーバー名指定でアクセスできる
• ネットワーク切断時に適切なエラーになる

問題が発生した場合は、Windows側、ネットワーク側、DNS側、Active Directory側、共有フォルダ権限などを切り分けます。

GUIとCUIを使った確認

IT業務では、画面上の結果だけでなくコマンドを使った確認も役立ちます。

Windowsキー + Rを押して「cmd」と入力すると、コマンドプロンプトを起動できます。

コマンド	確認できる内容
whoami	現在のログインユーザー
ipconfig /all	IPアドレスやDNS設定
ping	基本的なネットワーク疎通
nslookup	DNSによる名前解決

PowerShellでは「Get-NetIPConfiguration」などを使ってネットワーク構成を確認できます。

CUIの結果はコピーして記録しやすいため、テスト結果や障害調査の証跡にも役立ちます。

イベントビューアーでログを確認する

Windows上のアプリケーションやサービスでエラーが発生した場合は、イベントビューアーも確認します。

1. Windowsキー + Rを押す
2. 「eventvwr.msc」と入力する
3. Enterキーを押す
4. 「Windowsログ」を開く
5. 「Application」または「System」を確認する
6. テスト実施時刻付近のエラーや警告を確認する

イベントID、ソース、日時、メッセージを記録しておくと、不具合報告やエスカレーションがしやすくなります。

筆者が現場で失敗した例

実務で失敗したことの一つが、仕様書に書かれている正常パターンを中心にテストケースを作り、データが0件の場合を十分に確認しなかったことです。

通常データでは正常に動いていましたが、対象データが存在しない環境では想定していないエラーが発生しました。

コード自体は複雑ではありませんでしたが、「データは必ず存在する」という思い込みが原因でした。

それ以来、テストケースを考えるときは「ある場合」だけでなく「ない場合」を必ず確認するようにしています。

初心者がやりがちなテストケース作成のミス

• 正常系だけを書く
• 仕様書に書かれた例だけを使う
• 境界値を確認しない
• 期待結果が曖昧
• 前提条件を書かない
• ユーザー権限を変えて確認しない
• データが存在しないケースを忘れる
• 過去の不具合をテストケースへ反映しない
• ケース数を増やすこと自体が目的になる

テストケースは数が多ければよいわけではありません。

重要なリスクを効率よく確認できるケースを考えることが大切です。

テストケースを考える力を伸ばす練習方法

日常的にできる練習としておすすめなのが、身近な機能を見てテスト観点を考えることです。

たとえばログイン画面を見たら、次のように考えます。

1. 正しいIDとパスワードなら？
2. パスワードが違ったら？
3. IDが空欄なら？
4. 非常に長い文字を入力したら？
5. アカウントが無効なら？
6. 連続して間違えたら？
7. ネットワークが切れたら？

すぐに答えを確認できなくても構いません。

「他にどんな条件があるか」を考える癖をつけること自体がトレーニングになります。

過去のバグからテスト観点を増やす

不具合は、テストケースを考える力を伸ばすための重要な教材です。

バグが見つかったら修正して終わりにせず、次の点を整理します。

• どの条件で発生したか
• なぜテストで見つからなかったか
• どんな観点が不足していたか
• 他の機能にも同じ問題がないか
• 再発防止用のテストを追加できるか

こうして自分の中に「過去に壊れたパターン」を蓄積すると、別のシステムでも似た危険に気付きやすくなります。

現場で評価されるテストの考え方

新人のうちは、特殊なテスト技法をたくさん知っていることよりも、なぜそのテストが必要なのか説明できることが重要です。

たとえば、「0をテストしました」だけでなく、「仕様上の最小値が1なので、境界の外側として0を確認しました」と説明できる状態です。

テストケースには必ず理由があると考えましょう。

上司へ不具合を報告するポイント

テストで問題を発見したら、次の情報を整理します。

• 対象機能
• テスト条件
• 事前条件
• 操作手順
• 入力値
• 期待結果
• 実際の結果
• 再現率
• 影響範囲
• エラーメッセージ
• ログ
• 証跡

「エラーになりました」ではなく、誰が同じ操作をしても再現できる情報を伝えることが大切です。

エスカレーションするタイミング

次のような問題を発見した場合は、自己判断でテストを続けず早めに上司や担当者へ報告します。

• 本番データへ影響する可能性がある
• データ破損や消失が疑われる
• 権限のないユーザーが情報を閲覧できる
• 個人情報や機密情報に関係する
• 複数機能に影響する重大な問題
• サーバーやActive Directoryの設定変更が必要

テストのためであっても、本番データの変更、サーバー停止、権限変更などを無断で実施してはいけません。

応用として覚えたいテスト技法

テスト技法	概要
同値分割	似た結果になる入力をグループ化して代表値をテストする
境界値分析	入力範囲の境目を重点的に確認する
デシジョンテーブル	複数条件の組み合わせを表に整理する
状態遷移テスト	状態が変化するシステムの動きを確認する
回帰テスト	変更によって既存機能が壊れていないか確認する

最初からすべてを使いこなす必要はありません。

まず正常系、異常系、境界値、権限、データ不存在の5つを意識するだけでも、テストケースの幅は広がります。

関連するIT用語

• 単体テスト：関数やクラスなど小さな単位を確認するテスト
• 結合テスト：複数機能や外部システムとの連携を確認するテスト
• 回帰テスト：変更による既存機能への影響を確認するテスト
• テスト観点：何を確認するかという視点
• 期待値：テストで正しいと判断する結果
• 証跡：テスト結果を示す画面キャプチャやログなど

よくある質問（FAQ）

Q．テストケースが思いつかないときはどうすればよいですか？

まず「正常」「異常」「境界」「空」「権限」「外部障害」の6つに分けて考えてください。何もない状態から考えるより整理しやすくなります。

Q．テストケースは多ければ多いほどよいですか？

多ければよいわけではありません。同じ確認を大量に繰り返しても効果は限られます。リスクが高い場所や条件の境目を優先することが重要です。

Q．仕様書にないケースまで確認してよいですか？

仕様から合理的に考えられる異常操作や境界条件は重要な確認対象です。ただし、期待結果が仕様から判断できない場合は自己判断せず、設計者や上司へ確認します。

Q．テストケース作成が上達する一番の方法は何ですか？

実際に見つかった不具合を振り返ることです。「なぜこのケースを事前に思いつかなかったか」を考えると、自分に不足していた観点が分かります。

Q．開発者にもテストケースを考える力は必要ですか？

必要です。実装前からテスト観点を持つことで、条件漏れや例外処理の不足に気付きやすくなり、バグを作り込みにくくなります。

まとめ

テストケースを考える力とは、仕様書を見て項目を増やす力ではありません。

「正常ならどうなるか」「境目ならどうなるか」「空ならどうなるか」「権限がなかったらどうなるか」「外部システムが失敗したらどうなるか」と、さまざまな条件を想像する力です。

初心者はまず、正常系、異常系、境界値、データ不存在、権限の5つを毎回確認する習慣をつけましょう。

そして不具合が見つかったら、修正して終わるのではなく、「不足していたテスト観点は何だったのか」を振り返ります。

良いテスト担当者やエンジニアは、テストケースを大量に書ける人ではなく、壊れやすい場所を予測して重要なケースを選べる人です。