テストケースとは？確認観点の作り方をやさしく解説

「テストケースを作ってください」と言われて、何を書けばいいかわからなかった経験はありませんか。

テストケースはIT現場でよく使われる言葉ですが、実際に何を書くものなのか、どのくらい詳しく書けばよいのかがわかりにくいことがあります。この記事ではテストケースの基本と、確認観点の考え方をわかりやすく整理します。

この記事でわかること

テストケースとは、「何を確認するか」を具体的に書いた項目です。

「このシステムをテストします」というだけでは、何を確認したかが記録できません。テストケースを作ることで、「この操作をしたら、この結果になるはず」という確認項目が明確になります。

一般的に、テストケースには以下の項目が含まれます。

レストランの料理チェックリストを考えてみます。

「ハンバーグ定食が出せるかを確認する」というだけでは曖昧すぎます。そこで確認項目を具体的にします。

これがテストケースに相当します。「何をどうやって確認して、どうなれば合格か」を事前に決めておくことで、品質の判断が属人化しなくなります。

テストケースを作るとき、何を確認項目にすべきかに悩むことがあります。よく使われる4つの観点で整理します。

1. 正常系（うまく動く場合）
正しい入力をしたときに、期待通りの結果になるかを確認します。「正しいIDとパスワードでログインできるか」などです。

2. 異常系（おかしな入力をした場合）
間違った入力や予期せぬ操作をしたときに、適切にエラーが表示されるかを確認します。「パスワードを空欄のままログインしようとしたらエラーが出るか」などです。

3. 境界値（数値の端っこ）
数値の最大値・最小値など、境界にあたる値で正しく動くかを確認します。「1〜100の入力が可能な項目に、0や101を入れたらどうなるか」などです。

4. 業務シナリオ
実際の業務フローで使ったときに問題ないかを確認します。「新規ユーザー登録→ログイン→商品購入→注文確認メール受信」のような一連の流れです。

受け入れテストにおいては、発注者側がテストケースを用意することもあります。仕様書をもとに「自分たちが確認したいこと」を書き出し、それを使って確認します。

ただし、「何十項目もテストケースを作らなければならない」と気負う必要はありません。重要な機能・よく使う機能・リスクが高い操作を中心に確認項目を絞るのが現実的です。

開発チームが用意したテストケースをレビューする立場になることもあります。そのときは「業務シナリオ」の観点から「実際の使い方に合っているか」を確認するのが、非エンジニアやPMがレビューで貢献できるポイントです。

テストケースを詳しく書きすぎてしまう

操作の一つひとつを細かく書きすぎると、テストケースの作成と管理に膨大な時間がかかります。目的に合った粒度で書くことが大切です。

正常系しか書かない

「うまくいく場合」だけ確認しても、問題が見つかりにくいです。異常系・境界値の確認が漏れると、本番環境で初めて問題が発覚します。

期待結果を書かない

「操作する」だけ書いて「どうなるべきか」を書いていないと、テストを実施しても合否の判断ができません。

テストケースとテスト仕様書を混同している

テストケースは個別の確認項目、テスト仕様書はテスト全体の計画や方針をまとめたものです。両方が必要なプロジェクトもあれば、テストケースだけで管理するプロジェクトもあります。

テストケースの作り方と、テスト全体の考え方を学びたい方には、FEXシリーズのソフトウェアテスト入門講座がおすすめです。受入基準の考え方や、よくある観点漏れの防ぎ方も学べます。