ソフトウェア開発において、テストは欠かせない工程です。
テストを効率良く進めるためには様々な工夫が必要ですが、その一つとして重要なものがテストケースです。
本記事では、テストケースの書き方とNG例、テストケースの作成時のポイントについて解説します。。
テストケースとは？
テストケースとは、テストをどのように進めるのかを記載した指示書にあたるものです。
テストを実施するにあたり、何を確認するテストかだけでなく、テストの範囲やテストで使用できるURLなど様々なことが明確になっていることが重要です。
そのため、テストの指示書であるテストケースには、以下のような項目が記載される必要があります。
- テスト対象
- テスト観点
- 実行条件
- 実行手順
- 期待結果
- 結果判定（その他項目）
もしテストケースの記載内容が曖昧だったり、分かりづらく、間違っていたりすると、以下のような結果を招く恐れがあります。
- テスト対象ではない箇所をテストしてしまう
- 操作手順を間違って、期待結果通りにならず、誤って不具合と判定されてしまう
- テストしたい箇所が正しくテストされず、不具合を見逃してしまう
このような事態を避けるためにも、テストケースに必要な情報を記載し、適切な指示書を作成することが重要です。
悪いテストケースの例
適切なテストケースの書き方をご紹介する前にNG例として悪いテストケースをご紹介します。
それぞれの悪い点をみて、同様のテストケースにならないようにしていきましょう。
2-1 情報が不足している
【NG①：情報が不足している例】
| No | 実施手順 | 期待結果 | 結果 |
| 1 | 商品を検索する | 検索できること | |
| 2 | カートに入れる | カートに入ること |
上記のテストケースの場合、悪い点は情報が不足しているところです。
- 対象システムは？
- 対象システムの接続先（URL）は？
- Webブラウザでテストする場合、どのブラウザを使えばいい？
- 最初にログインは不要？
- 「商品を検索する」という手順は、ジャンルから選択していくやり方と、キーワードを入れて検索するやり方など複数あるが、どれのこと？
- 「カートに入ること」という期待結果は、商品は何でもいいので一つ入れば良いのか？
- 結果には何を書けばいい？
など、確認したいことがたくさん出てきます。
質問・回答に時間もかかりますし、質問しないでテストを行うと、どのレベルまでテストされたのかが不明のままになってしまう可能性が高くなるのです。
2-2 期待結果が複数記載されている
【NG②：期待結果が複数記載されている例】
| No | 実施手順 | 期待結果 | 結果 |
| 1 | 1.以下URLに接続する https://www.xxxyyy.co.jp/ 2.ログイン画面で以下のアカウント／パスワードを入力して、「ログイン」ボタンを押す アカウント：testaccount1 パスワード：testpass 3.左のメニューから「商品検索」ボタンを押す 4.「商品検索」画面、「商品名」フィールドに以下の文字を入力して「検索」ボタンを押す 文字列：「ソフトウェアテスト」 |
・ログイン画面が表示されること ・商品検索画面が表示されること ・検索結果の中に「ソフトウェアテスト」という文言の入った以下の商品が含まれていること 「ソフトウェアテストの教科書」／カテゴリ：書籍 「はじめて学ぶソフトウェアテスト技法」／カテゴリ：書籍 ・検索結果の中に以下の商品が含まれていないこと 「スマートフォンケース（赤）」 |
結果欄には以下の何れかを記載すること
OK / NG / 再確認OK / QA / 保留 / NT / N/A
上記のテストケースの悪い点は、期待結果が途中の結果も含めて複数記載されている点です。
この状態だと、商品検索画面は表示されているが検索結果は期待通りにはならなかった場合、結果欄へ記載に問題が生じます。
例えば、期待結果が全てOKではなかった場合、NGと記載することになります。不具合の改修を担当する開発者は、どこまでがOKで、どこがNGなのかが不明確になってしまいます。
そのためテスト実行者にヒアリングするか、あるいは開発者が再度同じテストを最初から行い、確認しなければなりません。
上記のテストケースでは効率の良いテストにはならないでしょう。
良いテストケースの書き方【項目別】
テストケースには以下の項目を記載する必要があります。
- テスト対象
- テスト観点
- 実行条件
- 実行手順
- 期待結果
- 結果判定（その他項目）
悪いテストケース例で述べたことを注意し、さらに以下の考慮を加えると、良いテストケースになります。
各項目別のテストケースの書き方について詳しくご紹介していきます。
テスト対象
テスト対象には、「ソフトウェアのどの部分をテストするか」を記載します。
対象によっては、大項目・中項目・小項目に分けて記載することもあります。
【例】大項目：ログイン画面、中項目：ログインボタン
テスト観点
テスト観点には「何を確認するのか」を記載します。不具合が起きやすいポイントや仕様通りに動作するかの視点を記載します。
【例】正しいID・パスワード入力時にログインできるか
実行条件
実行条件には「テストを実施するために必要な前提条件やシステムの状態」を記載します。
【例】有効なユーザーアカウントが存在していること
実行手順
実行手順には、テストを実施する際の操作手順やステップを記載します。
【例】
- ログイン画面を開く
- ID欄に「user01」と入力
- パスワード欄に「pass123」と入力
- 「ログイン」ボタンをクリック
期待結果
期待結果には「テスト実行した際にソフトウェアがどう応答すべきか、正しい結果」を記載します。
【例】ホーム画面が表示され、「ようこそuser01さん」と表示される
結果判定（その他項目）
テスターがテストを実施した際の結果判定の項目も用意しましょう。
期待結果と実際の結果を比較し、合否を記載していきます。
また、その他の項目としてテストケースに記載すべき項目には以下のようなものがあります。
・実施日
・実施者
・不具合の情報（バグIDなど）
・テストした環境・バージョン
・備考欄
より具体的に記載をすることで、誰がテストしても同じ結果を得られるテストケースが作成できます。
テストケースを作成する際の3つのポイント
テストケースを作成する際のポイントをご紹介します。
4-1 何を確認したいかを明確にする
テストケースを作成する際には、まず「何を確認したいかを明確にする」ことが重要です。
単に手順や期待結果を記述するだけでなく、そのテストケースがどの機能や仕様のどの部分を検証するものなのかを、明確に記載することを心がけましょう。
これにより、レビュー時の判断基準が明確になり、実施者ごとの解釈のブレも防ぐことができます。
特に、異常系のテストや境界値テストのように、仕様を深く読み込まないと意図が伝わりにくいケースでは、観点を記載しておくことで品質の高い検証につながります。
4-2 トレーサビリティを確保する
「トレーサビリティを確保する」ことも、非常に重要なポイントです。
トレーサビリティとは、テストケースと要件、設計仕様、さらには発見された不具合との関連性を追跡可能にすることを指します。
これを実現することで、仕様が変更された場合にどのテストケースが影響を受けるかをすぐに特定でき、メンテナンスやリグレッションテストの効率が大きく向上します。
テストケース内に要件IDや仕様書の該当箇所を紐づけておくことで、このような追跡性を確保できます。
4-3 テスト結果の集計が出来るような工夫をしておく
テスト実行後の管理や分析を考慮し、「テスト結果の集計ができるような工夫をしておく」ことも大切です。
具体的には、OK/NGなどの判定結果を整理しやすいように統一的な記載ルールを設けたり、実施日や担当者、テストステータスなどの管理項目をあらかじめ用意しておいたりするなどです。
これにより、進捗管理や品質分析が格段にしやすくなります。
特に複数人でテストを行うプロジェクトでは、集計可能な形式でのテストケース作成は、チーム全体の可視化と報告の効率化に直結します。
まとめ
ソフトウェア開発において、テストケースは品質を確保するための不可欠な要素です。
曖昧なテストケースは不具合の見逃しや誤判定を引き起こす可能性があり、テスト効率を著しく低下させます。
本記事では、テストケースに必要な項目の具体的な記載方法や、陥りがちなNG例を紹介しながら、誰が見ても理解できる明確なテストケースの重要性を解説しました。
また、テストケースを作成する際のポイントは以下の3つです。
- 何を確認するのかを明確にする
- トレーサビリティを確保する
- 結果の集計ができるよう工夫する
これらを意識することで、再現性が高く、品質と効率の両立を実現するテスト設計が可能になります。
テストケースを作成する際の参考にしてみてください。
バルテスでは、ISO/IEC/IEEE 29119（以下、29119規格）に対応したテスト計画プロセスに関するテンプレートを公開しています。
＞＞テストドキュメントテンプレート（ISO/IEC/IEEE 29119対応）
無料でダウンロードできますので、ぜひご活用ください。
★テスト設計をAIで自動化する「TestScape」
「TestScape」はバルテスが開発したAIテスト設計ツールです。
バルテス独自のAIが仕様書を読み込み、テストケースを自動生成します。その過程で、テスト設計書などの中間生成物も自動的に作成します。
テストの抜け漏れや、テスト担当者への負担増加、テストの属人化などの課題を解消したい方におすすめです。
