テストケースとは？記述のポイントを具体例で解説

HOME

ブログ

ソフトウェアテスト

テストケースとは？記述のポイントを具体例で解説

ソフトウェアテスト

公開日2020.11.27 最終更新日2024.07.29

1. テストケースとは
2. テストケースの目的
3. テストケースを作成するときのポイント
どの仕様や要件のものかわかるようにしておく
テスト手順は誰がやっても同じ内容になるよう記述する
【×悪い例】
【〇良い例】
期待する結果も記述しておく
【×悪い例】
【〇良い例】
4. まとめ

ソフトウェアテストを実行する際、テスターが必ず参照するのがテストケースです。テストケースにまとめられているのは、テストの手順だけではありません。テストケースを適切に実施するのに必要な、その他の情報が複数掲載されています。

この記事ではテストケースとはどういったものかやその必要性、どのような内容が記載されているかを解説しています。あわせてテストケース作成の際に気を付けるべきポイントもまとめているので、テストケースとは何か知りたい場合は参考にしてください。

テストケースとは

テストケースとは、ソフトウェアテストを実行する手順や利用するデータ、条件、期待される結果などを文章化したものを指します。ソフトウェアテストを実施する際に参照すべき、説明書のようなものと言えば分かりやすいでしょうか。（上記サンプルでは、赤枠で囲った部分がテストケースです）

テストケースは、以下にあげる項目で構成されます。

テストの対象	テストを実施する対象（特定の機能・UI等）
テスト観点	ソフトウェアが正常に動作していることを証明するために「何をどのようにテストすればよいか」という視点を定義したもの
前提条件	そのテストを成立させるために満たしておくべき前提条件
操作手順	テストを実行する際の具体的な手順
入力データ	テストを実行する際に利用するデータ
期待する結果	テストを実行し、どのような結果がでれば正常であるかを文章化したもの

テストケースの目的

テストケースを用意する目的の1つ目は、テストすべき内容の見落としを防ぐことです。ソフトウェアをどのように使うかはユーザーによって千差万別であり、中には開発者の想定していない内容も数多く含まれます。

そのため仕様書に基づいた、開発者視点のテストだけでは十分ではありません。必要なテストが行われず、リリース後にユーザーの利用によって重大なバグが発見されてしまうこともありえるのです。テストケースは、そのような漏れを防ぐために作成されます。

またソフトウェアテストをどのように行ったか、誰がみてもわかるように明確化しておくこともテストケースを用意する目的です。ソフトウェアテスト後にバグが発見された場合に、どのようなテストを行ったか見直す際にも、テストケースが必要となります。

テストケースを作成することにより、改めてソフトウェアテストを実施する際にどのようなテストが必要となるか検討しやすくなるのです。その結果、無駄なテストを行ったりすることなく効率的にソフトウェアテストを進められるようになります。

テストケースを作成するときのポイント

テストケースの概要や目的をみてきました。それではテストケースを実際に作成するときは、どのような点に注意すべきでしょうか。ここでは、テストケース作成時の主なポイントを紹介します。

どの仕様や要件のものかわかるようにしておく

個々のテストケースについて、ソフトウェアのどの仕様や要件に関連するものか明確化しておくことが必要です。このような関連付けのことを、ソフトウェアテストでは「トレーサビリティ」と言います。

トレーサビリティがしっかりしていれば、要件の追加や変更が生じた際のテストケースの見直しができるようになります。仮にトレーサビリティがないと、要件が変わった際に、どのテストケースをやり直したり変更したりする必要があるか分析できません。

当社AIQVE ONEでも、それぞれのテストケースがソフトウェアのどの仕様やテスト観点と紐づくか定義しています。

テスト手順は誰がやっても同じ内容になるよう記述する

テストケースは、使う人によって解釈の違いが出てしまうようではいけません。誰がそのテストケースを参照しても、全く同じ手順で同じ実行結果となることが望ましいです。

以下、分かりやすいようにテストケースの悪い例・良い例をみてみましょう。例として、RPGゲームで主人公が道具を購入するシーンを想定します。

【×悪い例】

操作手順
道具屋の画面を表示させて、道具を購入する

これでは手順が抽象的で、具体的にどのようにすべきか、どうなれば正しいといえるのかが分かりません。テスター（テストを実行する担当者）によって、解釈が異なってしまうことが考えられます。

それでは良いテストケースの例をみてみましょう。

【〇良い例】

操作手順
1. 道具屋のアイコンをタップする 2. 購入する道具（「薬草」）をタップする 3. 「OK」をタップする

このように操作手順が具体的であれば、テスターによって解釈が変わることはありません。誰が行っても、同じ結果が得られます。

期待する結果も記述しておく

テストケースを作成する際は、その手順を実行することで期待される実行結果についても記述しておくことが求められます。より具体的には、仕様書通りにテスト対象の機能が動作した際の結果のことです。この結果が具体的に記述してあれば、テスターが判断に迷うこともありません。テスト結果を正確に報告することが可能になります。

以下、期待する結果についても悪い例・良い例をみていきましょう。

【×悪い例】

操作手順	期待する結果
道具屋の画面を表示させて、道具を購入する	正しく道具が購入できる

これでは具体的に、「どうなっていれば」仕様通りと言えるのかがわかりません。

【〇良い例】

操作手順	期待する結果
1. 道具屋のアイコンをタップする 2. 購入する道具（「薬草」）をタップする 3. 「OK」をタップする	・キャラクターの持ち物に薬草が増えている・道具の売値分、所持金が減っている

このように期待される結果の内容が明確に記載されていれば、どのテスターがみてもどうなれば仕様書通りなのか判断できます。