テストケースの記法はプロジェクトや現場によって異なることが多いですが、ほとんどの場合以下の要素で構成されている事が基本となります。

1.評価対象

システムの何処をテストするのかを明記します。

主に画面やそのUIを指します。

2.評価観点

評価対象にどのような観点でテストを行うのかを明記します。

正常系、異常系といった評価アングルによる分類や、評価対象に備わっているどんな機能を見たいのか。

実施者が「なぜそのテストをするのか」という背景を理解することで、期待する結果と実動作による結果の照らし合わせをより正確に行うことができます。

3.前提条件

テストケースにおいて事前に準備しておく環境情報を明記します。

評価対象に影響を与える設定項目の値や、周辺機器の接続等。

手順の中で操作する設定値や機器情報はここに含めないよう注意してください。

実施者が混同して手順を誤る可能性があります。

4.手順

テストに必要な手順を明記します。

ここでのポイントは主に3つ

　・最初にスタート地点となる画面から書き出す

　・手順1つにつき1つの操作を書く

　・手順の中で何かしら設定を行う場合は具体的な値を指定する

いずれも操作導線を統一させることで実施者によるブレを防ぐのが目的です。

5.期待結果

そのテストケースで最終的に得られる結果、確認すべきシステムの振る舞いを明記します。

6.作成例

以下のような会員登録機能を持つ画面を例とします。


上記画面の要件・仕様は以下の通り

■要件

　・新規会員登録ができる

　・全ての欄で入力が必須

　・入力内容にエラーがある場合はユーザーにエラー個所を明示して修正を促す

　・戻るボタンを押したら入力済みの情報は破棄

■仕様

これらを踏まえてテストケースを作成すると以下のような形になっていきます。


テストケースのリストは件数が膨らむにつれフィルターによる絞り込みが必要になることがあります。

リストの左側にある評価箇所や評価観点の分類はその際に抽出や検索がしやすくなる書き方をしておくと利便性やメンテナンス性が上がります。

事前になにかしらの設定値やアプリを起動しておく等を書く際に、"任意で～"などの実施者に詳細を委ねる表現を可能な限り使わないことを推奨します。

例えば「High」「Medium」「Low」と3つの値を持つ設定項目があり、テスト手順にて「Low」に変更するものとする。

その場合前提条件として「High」「Medium」いずれかに設定していれば問題ありませんが、なるべくどちらにするかはテストケース側で指定するのが望ましいです。


これは

「同じ条件下で同じ画面から操作し、同じ値を入力・操作することで同じ結果を得られる」

というテストケースにする為で、期待結果の内容を明確にし、また不具合が発生した際に再現確認がしやすくなります。


例えば「最後に動画再生していたアプリを表示する」という機能を評価する為の、以下のテストケースがあるとします。


これを見てある実施者は端末内にプリインストールされているプレーヤーアプリで動画を再生し、別の実施者はYoutubeアプリで動画を再生していずれも同じ結果を得たとします。

結果的には問題ないように感じますが、プリインストールされているアプリと外部アプリであるYoutubeがシステムに全く同じ振る舞いを与えているとは限りません。

そうなるとこの2人の実施者はそれぞれ異なる環境下で評価していたことになり、このような評価はテストケースを長期運用するほどより大きなリスクとなります。


また後からバグが確認された際に「なぜ過去のテストでは発見できなかったのか」という問題にも繋がる為、複数の状態を網羅したいのであれば都度テストケースを分けるのが望ましいです。

以上、テストケースを作成する際に意識するべきことをまとめました。


現場によってはテストの設計者と実施者が分かれており、その場合テスト実施者は必ずしもシステムの仕様や背景を理解しているとは限りません。

また設計者自身にとってもある程度期間が空くと設計時の意図が不明瞭になることがあります。


システムを初めて見る人でも正しく動作結果を得られるテストケースの作成を心掛けることで安定して品質の高いシステム評価が可能となります。