ユースケーステストとは、実際にシステムを使うユーザー(≒アクター)の目線で行うソフトウェアテストの種類を指します。ユースケーステストでは、実際にユーザーなどがシステムを利用する状況を踏まえてテストを実行可能です。この記事では、ユースケースとは何かや、よく比較されるシステムテストとの違いについて解説します。

ユースケースとは

ユースケースとはアクター(≒ユーザー)がシステムを使い目的を達成するまでの、具体的な操作手順や操作結果の流れをまとめたものです。たとえばRPGゲームで、ゲームプレイヤーが主人公たちの体力(HP)を回復させるために宿屋へ泊まりたいとします。このときゲームプレイヤーが主人公を操作し宿屋へ泊まらせ、HPを回復させるまでの流れがユースケースです。

なお、ユースケースで言うところのアクターは、必ずしもゲームプレイヤーのようなエンドユーザーとは限りません。システムを操作する管理者や、何がしかの目的で対象システムを利用する外部システムなどもアクターに含まれます。アクターとは目的を達成するために、対象システムに関わる外部の存在を総称する用語と理解すれば分かりやすいでしょう。

ユースケースの種類

ユースケースは、その対象によって以下にあげる種類に分けられます。

<ビジネスユースケース>

ビジネスシーンにおいてアクター(主に顧客)が目的を達成するために、対象ビジネスを利用する際の流れをまとめたユースケースです。たとえば顧客が自身の目的を果たすため、ショッピングサイトで商品を購入する流れがあげられます。

<システムユースケース>

エンドユーザーや外部システムといった特定のアクターが、目的達成に向けシステムを利用する際のやりとりをまとめたものです。

ユースケースの作成

一般的にユースケースは、「ユースケース図」「ユースケース記述」から構成されます。そのためユースケースの作成とは、これら2つを用意することを指します。以下、ユースケース・ユースケース記述それぞれの概要について解説します。

ユースケース図

ユースケース図とは、文字通りユースケースを図にしたものです。ユースケース図では、アクターの目線で、システムのやり取りを図にして表現します。
実際にユースケース図がどんなものになるか、以下の例を参考にみてみましょう。

<例>
RPGゲームの中で、プレイヤーが主人公の体力を回復させるため、道具屋へ行って薬草を購入しその場で利用する。

上記ユースケースをもとに作成したユースケース図が以下です。
ユースケーステスト例

このようにユースケース図では、プレイヤーとシステムとの具体的なやり取り内容を図にしてまとめます。

ユースケース記述

ユースケース記述とは、ユースケースにおけるアクターとシステムがやり取りする内容をテキスト形式で具体的にまとめたものです。一般的にユースケース図1つにつき、1つのユースケース記述を作ります。ちなみに、後述するユースケーステストで直接的に利用するのは、ユースケース図でなくユースケース記述です。

ここではユースケース図で挙げた例をもとに、簡易的なユースケース記述の例をみてみましょう。

ユースケース名薬草で主人公のHPを回復させるユースケース
目的主人公のHPを回復させる
アクタープレイヤー
事前条件主人公のHPが減っている
事後条件主人公のHPが回復している
基本フロー ・道具屋に話しかける
・道具屋で薬草を購入する
・主人公に薬草を使う

このように、ユースケースの詳細をフォーマット(項目)に従い具体的にまとめるわけです。ユースケース記述では様々なフォーマットがありますが、主な種類として以下があげられます。

ユースケース名 ユースケースの名前。
※ユースケース図に記載の名前と同じにする
目的ユースケースを実行することで達成される目的の内容
アクターユースケースに関連するアクター
事前条件ユースケース実行時に、あらかじめ整っているべき条件
事後条件ユースケース実行後に満たされるべき条件
基本フロー ユースケースにおいて、アクターとシステム間で行われるやり取りの内容
※想定通りの内容をまとめる
代替フロー 基本フローの代替となるやり取り。代替フローでも事後条件が達成される必要がある
例外フロー ユースケース実行を中止しなくてはならなくなる手順。例外フローでは、事後条件は達成されない。
備考 上記項目にはあてはまらない内容

ユースケーステストとは

ユースケーステストとは、アクター(ユーザー)が実際にシステムを利用するシーンを想定し、ユースケースに基づき行われるテスト技法です。ユースケーステストはブラックボックステスト※1)の1つに分類されます。ユースケーステストで使われるテストベース※2)は、ユースケース図ではなくユースケース記述です。

なお、ユースケーステストは、あらかじめ使われ方がある程度固定されているソフトウェアやシステムに適していると言えます。ゲームのようにプレイヤーごとに遊び方が千差万別である場合、ユースケースが膨大になるためユースケーステストはあまり適していません。仮に行うとしても特定のクエストを進行するケースなど、ユースケースが限定される場合に限られます。

※1)ブラックボックステストとは
システムの内部構造を考慮せずに行われるソフトウェアテストの種類です。
※2)テストベースとは
テスト実施内容をまとめる「テストケース」を作成するにあたって、参考にする資料のことです。

ユースケーステストのテストレベル

ユースケーステストは、エンドユーザーや顧客も参加する「受け入れテスト」※1)の段階で行うのが効果的です。「統合テスト」※2)において、インターフェースを原因のバグを検出したいときにも、ユースケーステストは適しています。一方、特定の機能ごとにテストをする「コンポーネントテスト」※3)では、ユースケーステストは採用されません。

※テストレベルとは
開発の各段階に応じ、実施されるソフトウェアテストの段階がかわります。この段階がテストレベルです。
※1)受け入れテストとは
ユーザーの目線で、対象のソフトウェアがユーザーの要求を満たしているか確認するテストの種類です。ユーザーが実際にシステムを利用する際の環境に出来る限り近づけてテストを行います。
※2)統合テストとは
2つ以上の機能を組み合わせて、想定通りに動作するかチェックするためのテストです。コンポーネントテストのあとに行われます。
※3)コンポーネントテストとは
特定の機能(コンポーネント)に対するテストです。

ユースケーステストのカバレッジ

ソフトウェアテストでは、必ずしも想定可能な全てのパターンでテストが行われるとは限りません。予算・納期・求められるクオリティなどに応じ、テストを行う範囲が決定されます。ソフトウェアテストにおけるカバレッジとは、テストを行う(行った)範囲や割合のことです。

ユースケーステストにおいてカバレッジをどう決めるかに関して、公式的な見解はありません。ただしプログラムにおいて実行結果がかわる条件全てを、最低1回はチェックできるようテストケースを設計するのがよいとされています。

ユースケーステストとシナリオテストの違い

シナリオテストとはユーザーが実際に利用する手順に基づいて操作を行い、問題が発生しないかチェックするテストです。ユースケーステストとシナリオテストは同じと解釈されることも多いですが、実際には違いがあります。

ユースケーステストは、あらかじめまとめたユースケースに基づき行われるテストです。一方のシナリオテストは、ユースケースより高い自由度のシナリオに基づき実行されます。たとえばシナリオテストなら、2つ以上のユースケースを横断するようなシナリオを作ってテストをすることも可能です。

一方、ユースケーステストでは、ユースケース図・ユースケース記述によって条件が明確化されます。これにより、あとからトレーサビリティ・網羅性をチェックしやすいのが特徴です。

まとめ

ユースケーステストとは、アクターがシステムで目的を達成するまでの流れをまとめた「ユースケース」に基づいたテスト手法です。ユースケーステストは、受け入れテストや統合テストなどの段階で行うのが適しています。

またユースケーステストはシナリオテストと同義とされる場合もありますが、その特徴には違いもありきちんと把握しておきたいところです。シナリオテストは、ユースケースより自由度の高いシナリオによって実施されます。一方、システムとのやり取りが明確化されたユースケースに基づき行われるため、トレーサビリティや網羅性をチェックしやすいのが特徴です。