1．概要
テスト計画、設計と続き、次はテストケースについて説明します。テストケースはテストの手順を記載するもので、おそらく多くの人がテスト中に使用しているドキュメントではないかと思います。
ただ、会社によっては無茶苦茶たくさんの記載項目のあるテストケースを採用し、非常に不便な状況にある人もいるのではないでしょうか？
今回はIEEE829のテストケースを説明しながら、テストケースの項目について説明したいと思います。
2．IEEE829のテストケースとは？
IEEE829のテストケースでは、主に以下の項目を記載します
- テストケース識別子 ⇒性能テスト、機能テストなど、何のテストケースなのか判断する番号や記号等を記載
- テスト目的 ⇒どの部分をテストするのか目的を記載
- 入力 ⇒テストの手順を記載
- 期待される結果 ⇒入力の結果、どんな結果が返ってくるのか記載
- 環境要件 ⇒テストを実施する環境を記載（バージョン情報やインフラの情報など）
- 手順に関する特記事項 ⇒入力が複雑な場合、注意事項を記載する
- テストケース間の相互関係 ⇒どのケースとどのケースが関連しているか記載する（大抵テストケース識別子に含まれることが多い。）
上記がテスト実施を行う上で、テストケースに記載しなければならない最低限の項目になります。もし上記以外の記載があれば、テストを進める以外の目的が含まれているということになります。
3．テストケースの考え方
テストケースには、主に以下3つの目的のために各項目を記載します。
- テスト実施を進めるための項目 ⇒入力、期待結果、環境要件など（IEEE829のほとんどの項目が該当）
- 管理のための項目 ⇒ステータス（OK、NGなど）、実施者名、実施日など
- 分析のための項目 ⇒分類（エラー確認、データ抽出など）、テスト実施にかかった時間など
テスト実施を進めるだけであれば「1」の項目さえ記載していれば問題ありません。ただ、実施がきちんと進んでいるか、管理しなければならないケースがほとんどだと思いますので、「1」、「2」の項目が記載されているケースが一般的だと思います。
そして「3」の分析項目ですが、ここが大抵形骸化していることが多く、何のために記載しているのか、何を分析しているのか、わからなくなっていることが多々あります。
そのため、「3」に該当する項目は適宜見直し、特に使われていないようであれば削除した方がよいと思います。
※分析項目は、放置すると際限なく項目が増えていく部分でもあるので…
まとめると、もし自社向けのテストケースを作成するのであれば、
「1」テスト実施の項目 ⇒「2」管理のための項目 ⇒「3」分析のための項目
の順序で記載する項目を決めていくのが、作りやすいのではないかと思います。
また、「1」に該当する項目は必ず記載しなければならないというわけではありません。テストの進め方は、開発方法（V字、アジャイルなど）や分野（組込みシステム、Webシステム、基幹システムなど）によって変わりますので、その都度適しているものを選んでください。
4．テストケースの各項目
3章の3つの分類に従いネット上にあったテストケースの項目を分類すると、以下のようになります。もし自社向けテストケースを作成しているのであれば、参考にしてみてください。
※分類：①テスト実施を進めるための項目、②管理のための項目、③分析のための項目
| 項目名 | 分類 | 説明 |
|---|---|---|
| システム名 | ②、③ | どのシステムをテスト対象としているか、管理のために記載する。また、システム名と不具合数を合わせるなどして、分析のために使うこともある |
| サブシステム名 | ②、③ | どのサブシステムをテスト対象としているか、管理のために記載する。また、サブシステム名と不具合数を合わせるなどして、分析のために使うこともある |
| モジュール名 | ②、③ | どのモジュールをテスト対象としているか、管理のために記載する。また、モジュールと不具合数を合わせるなどして、分析のために使うこともある |
| 機能名 | ②、③ | どの機能をテスト対象としているか、管理のために記載する。また、機能名と不具合数を合わせるなどして、分析のために使うこともある |
| 画面名 | ②、③ | どの画面をテスト対象としているか、管理のために記載する。また、画面名と不具合数を合わせるなどして、分析のために使うこともある |
| テスト工程 | ②、③ | 単体テスト、結合テストなど、どのテスト工程か記載する。工程ごとの不具合数を洗い出し、移行判定に使うことがある。ただし、開発工程がきちんと区切られていない（工程間のタスクがきちんと分けられている）と分析に利用できない |
| 作成者 | ② | テストケースの作成者を記載する。何かあれば質問するために利用 |
| 作成日 | ② | テストケースの作成日を記載する。スケジュールの確認のために利用する |
| 更新者 | ② | テストケースの更新者を記載する。更新内容に疑問点があれば、質問するために利用 |
| 更新日 | ② | テストケースの更新日を記載する。最新版がどれか確認のために利用 |
| 分類 | ③ | 何を分類したいかによって内容は変わる。どんなテスト内容が多かったのか分析のために使う場合は、「エラーチェック」、「遷移確認」などを記載。 |
| テストケースNo | ① | テストケースを一意に表す番号。これあるとどのテストケースで問題があったか、認識を合わせやすい |
| 項目数 | ②、③ | テストケースの総数を記載。管理に使う場合は、項目数と実施数から消化率を出す。また、分析に使う場合は、項目数と不具合数で検出率を出したりする |
| 実施数 | ②、③ | テストケースの実施している数を記載。管理に使う場合は、項目数と実施数から消化率を出す。分析に使う場合は、項目数と不具合数でその時点の検出率を算出したりする |
| バグ数 | ② | そのテストケースで見つかった不具合数を記載。管理に使う場合は、バグ数と修正数で管理を行う。分析に使う場合は、不具合管理表の方に詳細記載するので、テストケースにはこれ以上の詳細は記載しないことが多い |
| 不具合No. | ② | 不具合を一意に表す番号。これがあると、どの不具合とどのケースが関連しているのか、認識を合わせやすい |
| 前提条件 | ① | テストを実施する際に事前に設定していなければならないことを記載。 |
| テスト環境 | ① | どんなテスト環境で実施するのか記載。環境名、プラウザ名、バージョンなどを記載します |
| 操作手順 | ① | テストの手順を記載する。詳細に書けば、実施の精度が上がるが作成に時間ががかる。あいまいに書けば、テストケースの作成は早いが実施のミスが起きる可能性がある |
| 期待結果（判定基準） | ① | 操作手順後にどうなっていれば正解か記載する |
| 再現率 | ① | どのくらいの頻度で不具合が発生するのかを記載。ただ、組み込み系などのタイミングによって結果が変わるシステムには必要な項目。Web系ではあまり見かけない |
| 実施結果 | ① | 実際に実施した結果を記載する。OK、NG、NA等記号で記載することが多い |
| 備考 | ① | テスト実施中に気になったことがあれば、ここに記載する |
| 特記事項 | ① | 備考欄と同じ項目。言い方が違うだけ |
| 実施者 | ②、③ | テストを実施した担当者名を記載する。誰がテストを行ったのか、管理のために使う場合と、不具合数などと合わせて分析に使う場合もある |
| 開始日 | ② | テストの開始日を記載。管理のために利用 |
| 開始予定日 | ② | テストの開始予定日を記載。予定と実績の差異を見るために利用 |
| 終了日 | ② | テストの終了日を記載。管理のために利用 |
| 終了予定日 | ② | テストの開始予定日を記載。予定と実績の差異を見るために利用 |
| 実施時間 | ②、③ | テストケースの実施にどのくらい時間がかかったのか記載。分析に使う場合は、項目数と実施時間を合わせて、実施者の生産性を測ったりする |
5．まとめ
テストケースはテストを実施する上で必要なドキュメントですが、そこに記載する項目には、それぞれの目的があります。その目的に合うようであればそれを記載し、逆に合わないようであれば項目の削除を検討するべきだと思います。
そうしないと大抵テストケースの記載項目が膨大となり、テスト実施者を苦しめるだけの結果が待っています…