2023.04.07

テストケースとは？書き方や満たすべき要件について解説

著者株式会社SHIFT　マーケティンググループ

Introduction

「テストケース」は、ソフトウェアテストで確認すべき内容や、テストの条件、テスト実行の手順、期待する結果などをまとめたものになります。例えば、Web画面上でデータを入力したり、ボタンを押下したりといったテスト実行時の操作は、テストケースに書かれている内容をベースに行われます。そのため、テストケースは確実なテストを実施するために重要な役割を担います。本コラムでは、テストケースとは何か、テストケースに記載されるべき内容などについて解説します。

「テストケース」とは

「テストケース」はJSTQB用語集(※1：ソフトウェアテスト標準用語集Version2.3.J01)では、「実行事前条件、入力値、アクション(適用可能な場合)、期待結果、および実行事後条件のセットであり、テスト条件に基づいて開発されたもの」と定義されています。ソフトウェアテストを実施するためには、具体的な確認内容や期待値などをまとめた「テストケース」が必要になります。
テストケースには読み手がいます。テスト実行者、他のテスト設計者、レビュアー、開発者などです。これらの読み手にテスト内容が伝わるように書かなくてはなりません。さまざまな読み手が理解できるように記述しておかなければ、テストケースとして意味のないものになってしまいます。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

「テストケース」の目的と最低限満たすべき要件

テストケースの目的は、テスト計画、テスト設計の方針で決めた通りにテストを実施できるようにすることです。その目的を達成するために、テストケースが最低限満たすべき要件は以下の2つになります。

インプットとなるテスト計画書、テスト設計の方針の内容を踏まえていること

テストケースのインプットには、テスト計画書およびテスト対象、テスト観点、テストケースの書き方などをまとめたテスト設計の方針があります。
これらのインプットには、プロジェクトで実現すべきテストの内容が記載されています。インプットの内容をよく理解しないままテストケースを作成すると、確認不要なテスト観点のケースをつくってしまったり、必要なテスト対象を見落としたりするなど、テストケースの過不足が起きる恐れがあります。そして、テストケースの過不足は、作業工数の超過や不具合の見落としにつながってしまいます。

テスト実行者が迷わずテストを実施できること

テストケースをテスト実行者が見たときに、何をどのようにやればよいのかわかる記述になっていることです。これは、テスト実行者によって解釈がぶれないように記載することが重要になります。もし、テスト実行者がテストを実施する際に誤った解釈をしてしまったら、テスト結果NGとして報告されるべきケースが結果OK（問題なし）として報告され、不具合を見逃してしまう原因となります。

テストケースのつくり方

テストケースの目的を達成するために、テストケースに最低限必要な項目は「テスト対象」「テスト観点(確認内容)」「テスト条件」「テスト手順」「期待値」になります。

テストケースのフォーマットはプロジェクトや組織で決まったものを使っていることが多いですが、必ずこれらの項目ではなければならないという意味ではありません。ただし、テストケースはこの5要素を押さえている必要があります。SHIFTでは、この5つの要素をテストケースに記載することを基本としています。

テスト対象

テストで確認する対象を記載します。(図1：①)対象が階層構造になっている場合は、項目をわけて書く場合もあります。上記の例では、「どの画面のどの項目をテストするのかを明確にする」という考えに基づいて分割の方針を立て、「画面」「項目」という単位に2段階で分割しています。どのように分割するかは、テストケース作成前にテスト対象にあわせて方針を決めます。システムの規模によっては2段階ではなく、3段階以上に分割することもあります。大切なのは、どの部分をテストするのかが読み手に伝わるように記載することです。

テスト観点・確認内容

何を確認するか、一読してそのテストケースの目的・意図が把握できるように記載します。(図2：②)例えば、1円未満の端数の計算処理を確認したい場合、テスト観点は「端数処理」とします。そして、確認内容には、「1円未満の端数の金額が切り捨てられることを確認する」というように、より具体的なチェックポイントを記載します。

テスト条件

テスト結果に影響をおよぼすだろう要素をあげていきます。(図2：③)例えば、システムの状態や入力データ、操作のバリエーションなどです。これらの要素について、取り得る値や状態を検討します。そして、テスト設計技法を利用して、要素の組み合わせを決定したり、テスト設計の方針で定めた網羅の基準を満たすための入力値を洗い出したりします。

テスト手順

テストで確認すべき結果が出力されるまでの作業手順を記載します。(図2：④)テスト手順は、テスト実行者が誤りなく操作できるようにします。画面名や項目名などはシステム仕様書に定義されているものをそのまま使用すると誤解が少なくなります。また、長い文章で1つにまとめるのではなく、操作ごとに改行するなど見やすさを心がけましょう。

期待値

どういう状態になっていたらテスト結果を合格とするのかを書きます。(図2：⑤)このとき、読み手によって解釈が異なってしまわないように注意しましょう。項目名や表示内容を具体的に書くことが望ましいです。

ハイレベルテストケースとローレベルテストケース

テストケースは記述粒度の違いにより、ハイレベルテストケースとローレベルテストケースにわけることができます。

ハイレベルテストケース

抽象的な事前条件、入力データ、期待結果、事後条件、およびアクション(該当する場合)を含むテストケース

ローレベルテストケース

具体的な事前条件、入力データ、期待結果、事後条件、およびアクション(該当する場合)を含むテストケース、ハイレベルテストケースの入力データや期待結果に具体的な値を設定することにより、ローレベルテストケースになります。

	ハイレベルテストケース	ローレベルテストケース
記載内容	抽象的	具体的
作成コスト	小さい	大きい
保守性	高い(修正箇所が限られ、影響範囲が小さくなる)	低い(修正箇所が多くなり、影響範囲が大きくなりやすい)
テスト実行難易度	高い(具体的な入力値や手順を判断しながらテストを実施するため、テスト目的やテスト対象を理解している必要がある)	低い(テスト目的やテスト対象をあまり理解していなくても、手順通りに操作することによりテストを実施できる)
カバレッジ	高くなることがある(テストを繰り返すごとに入力値を変えた場合にカバレッジが高くなることがある)	一定(つねに同じ値で確認するため、カバレッジが一定に保たれている)
再現性	低くなることがある(テストを繰り返すごとに入力値を変えた場合に再現性が低くなることがある)	高い(つねに同じ値で確認するため、再現性が高い)

表1 ハイレベルテストケースとローレベルテストケースの比較

具体的な例は以下になります。
ハイレベルテストケースは、ローレベルテストケースに比べて、抽象的な記載になり、どのようなテストをするのかという指針が示されている状態になります。ローレベルテストケースは、入力するデータやテスト手順、期待値に具体的な情報が付加されており、テスト実行者がそのままテスト実施できるようになっています。

ハイレベルテストケースとローレベルテストケースの例 — 図2 ハイレベルテストケース(上)とローレベルテストケース(下)の例

一般的に推奨されるテストケース作成の進め方としては、ハイレベルテストケースを作成した後、ハイレベルテストケースのテスト条件となる入力データやテスト手順、期待値などに具体的な値を記載していきます。例えば、ハイレベルテストケースのテスト条件では、「税込み後に1円未満の端数が発生する金額の購入可能な任意の商品」をしていた場合、ローレベルテストケースでは、「購入する商品：飲料A、・消費税率：8%・単価：1010円(税込み後に1円未満の端数が発生する金額)」としていきます。

ハイレベルテストケースを先に作成するメリットは、具体的な手順の作成やデータの準備をする前に、テストで確認したいことや網羅しようとしていることが可視化されることです。このように進めると、作成しようとしていたテストケースの内容に誤りがあった場合でも具体的なテストデータをすべて入力する前に修正が可能になり、手戻りや修正工数が少なくなります。また、ハイレベルテストケースで検討した内容が記載されていると、テストケースの目的がわかりやすいため、繰り返しテストを実施する際に入力データの値を書き替えるだけで済むなど、テストケースの再利用がしやすくなります。

ハイレベルテストケースを作成するメリットは他にもあります。要件や仕様の確定前や検討中であっても着手しやすいことです。例えば、画面の処理仕様が完全に確定する前まではテスト手順に「商品を購入する」とだけ記載しておき、仕様確定後「1.商品購入画面でテスト条件の商品Aを選択、2.商品購入画面で数量「1」を選択・・・」というように、具体的な画面名に書き換えることで、仕様確定前にもテストケースの作成を進めておくことができます。

ここまで、一般的な進め方を解説してきましたが、要件や仕様がすでに確定し、作成するべきテストケースが明確になっているようなプロジェクトでは、最初から具体的な値を記載したローレベルテストケースを作成することがあります。また、テストケースの作成工数を削減するためや再利用を考慮し、あえて具体的な値を記入せずハイレベルテストケースのみを作成し、テストを実施する場合もあります。しかし、この場合は、テストに必要な値や手順が明記されていないため、テスト実行者はテスト対象やテスト目的をよく理解していることが必要です。

品質保証のプロであるSHIFTでは、テスト対象の難易度やテスト実行者のスキル・理解度、テストケースの再利用の有無などプロジェクトの状況に合わせて、テストケースにどこまで具体的に書くのが適切かを判断し、記載粒度を調節しています。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞品質コンサルティング／品質PMOのページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

テストケースの入力値

テストケースの入力値を検討するにあたり、ブラックボックステストの技法としてJSTQBでは以下を紹介しています。

同値分割(同値クラス分割)

同値分割とは、出力が同等になると想定される入力値のグループ(同値クラスや同値パーティション)を識別し、各グループに対するテストケースを作成する技法のことです。有効または無効のような同様の結果をもたらす値を、それぞれ「同値クラス」として分類し、最低1回、各同値クラスのグループから実行するように設計するのが原則になります。

境界値分析

境界値分析とは、仕様条件の境界となる値とその隣の値に対してテストする技法のことです。境界値とは、ある範囲の最小値または最大値などの同値分割した領域の端にあたる値です。具体的には「未満」や「以下」などが該当し、こういった境界部分は、間違いを引き起こしやすく、不具合が潜んでいる可能性が高いとされます。

境界値を狙ってテストすることで、仕様の認識ミスや実装ミスによる不具合を検出できます。

同値クラス分割、境界値分析についてはこちらをご覧ください。
＞＞テストケースを作成する手法「境界値分析（限界値分析）」について解説のページへ

デシジョンテーブルテスト

デシジョンテーブル(decision table)は、想定されるすべての条件と、それに対して実行すべき動作を整理した表のことです。デシジョンテーブルを使用して論理的な条件をカバーし、入出力の組み合わせを規則ごとに実行するテストケースを設計するテストを「デシジョンテーブルテスト」といいます。入力する条件の組み合わせによって実行結果が変わる場合に有効であり、起こり得ない条件の組み合わせの把握や、それによるテストケースの効率化にも役立ちます。

デシジョンテーブルテストについてはこちらをご覧ください。
＞＞「デシジョンテーブル（決定表）とは？メリットや書き方をわかりやすく解説のページへ

状態遷移テスト

「状態遷移」とは、ソフトウェアやシステムの状態がさまざまな条件やイベントによって変化することを指します。それらの変化を図形や矢印で表現したものが「状態遷移図(ステートマシン図)」、状態とイベントをマトリクスで表現したものが「状態遷移表」です。
状態遷移テストは、状態遷移図や状態遷移表を基に「有効な状態遷移が正しく行われること」、「無効な状態遷移が行われないこと」をテストします。

状態遷移図についてはこちらをご覧ください。
＞＞状態遷移図とは？書き方や状態遷移表との違いをわかりやすく解説のページへ

まとめ

今回は、「テストケース」の目的やテストケースのつくり方、テストケースの記載粒度、テストケースの入力値について解説をしました。テストケースはテスト実施の精度や効率に大きく影響を与えます。テストケースの作成にあたっては、今回紹介しましたようにテストケースの記載粒度を調整したり、テスト技法を目的にあわせて使いわけたり、相互補完したりすることによってより効果的なテストを実施することができます。

株式会社SHIFTでは、開発の上流工程からテストまでの一気通貫でのシステム開発を請け負っています。多数の導入実績を誇っており、あらゆる分野の開発に携わってきました。

また、一部分だけのご依頼も可能です。本記事で紹介したソフトウェアテストだけの実施でもご相談ください。特にソフトウェアテストは弊社が力を入れてお客様のサポートをさせていただいている分野です。安心・安全にソフトウェアを使うためにも、ソフトウェアテストでお困りであればぜひSHIFTまでお問い合わせください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

テストケースとは？書き方や満たすべき要件について解説

Introduction

「テストケース」とは