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

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

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

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

▼あわせて読みたい▼
＞＞テスト計画とは？目的や種類・作り方・注意点をわかりやすく解説のページへ
＞＞テスト計画書とは？作成方法やポイントをわかりやすく解説のページへ
＞＞テスト観点とは？必要性や洗い出すための要素、つくり方を解説のページへ

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

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

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

▼あわせて読みたい▼
テスト仕様書の書き方～テストケース作成のポイント～
テストケースを作成する手法「境界値分析（限界値分析）」について解説

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

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

▼あわせて読みたい▼
テスト観点とは？必要性や洗い出すための要素、つくり方を解説

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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