シェア
ツイート
ブックマークユースケーステストとシナリオテストの違いを意識していますか？
ユースケーステストとシナリオテストは、ブラックボックステストに分類されるテスト設計技法ですが、両者が区別されずに扱われることも多く、テストに長年携わっていてもよく分かっていないエンジニアは少なくありません。
ユースケーステストとシナリオテストの違い、およびユースケースの記述方法を解説します。
ユースケースの意味
ソフトウェアテストにおいて、ユースケースとは、アクター（テスト対象のシステムとやりとりするユーザーあるいはシステム）とテスト対象との間での相互作用を表現したものであり、ステークホルダー（※1）の目的や要求およびそれらに照らし合わせたシナリオの集合です。
一方シナリオそのものは、アクターとテスト対象との間の一連の手順を表したものですが、非公式な（文書化されない、管理されない、レビューされないような）扱われ方をされる傾向が高く、またやみくもにテストの観点を入れることで発散や偏りを生じさせてしまう傾向も高いです。
ユースケースは、シナリオそのものよりも公式的に扱いやすくし、ステークホルダーの要求を引き出すことや確認することができるツールです。
ユースケースドキュメントやユースケース図などの形式で表現できます。
※1 ステークホルダー：プロジェクトメンバーのようにテスト対象のプロジェクトに積極的に関わっているか、顧客やユーザーやスポンサーのように自らの利益にプラスまたはマイナスの利益を受ける個人や企業
ユースケーステストの意味と目的
ユースケーステストは、ユースケースをテストベースとしたテスト設計技法であり、ユースケースの持ついくつかの特性を引き継いでいます。
ユースケースの観点で列挙されたシナリオに対するカバレッジを求めることができます。また、やみくもにテストケースが発散してしまうことを防ぐことができ、逆にユースケースの観点における、シナリオの列挙漏れなどの欠陥を検出することも期待できます。
ステークホルダーの要求からユースケースを介してテストまでのトレーサビリティ（※2）を確保しやすくなります。トレーサビリティが確保されれば、要求の重要度に基づいたテストの優先度付けを行うこともできて、ユースケース図を用いてアクターやユースケース同士の関係を俯瞰することができます。
※2 トレーサビリティ：要求や設計やテストなどのドキュメントとテスト対象のシステムを追跡し識別する能力
ユースケーステストとシナリオテストの違い
ユースケースは、ユースケースの形式や観点に従いステークホルダーの目的や要求やそれに照らし合わせたシナリオの集合であり、その集合をベースにしてテスト設計する技法がユースケーステストです。
シナリオテストは、シナリオをベースにテスト設計する技法です。
ユースケーステストも一部にシナリオを使っているため、「ユースケーステストはシナリオテストと同じ」と思われがちですが、ユースケーステストには、シナリオテストにはないトレーサビリティや網羅性の利点があります。
一方、シナリオテストにはユースケーステストにはない利点があり、ユースケースの制約によってユースケースには含まれないようなシナリオをベースに自由度の高いテスト設計ができます。
ユースケースの記述例を解説
ユースケースの記述には、決まった形式はなく、一般的に使われているような記述例を紹介します。
ユースケースは、ステークホルダーの要求を確認するためのツールでもあるため、専門知識がなくても読み取れるような言葉で記載します。また、あまりに詳細に書くとかえって要求分析の邪魔になってしまうため、流れが明確に分かる程度で記載するようにします。
商品を買い物カートへ入れる際の動作をもとにした、ユースケースをご紹介します。
| ID & ユースケース名 | UC-ORD01 商品を買い物カートへ入れる | |
| 目的 | 商品詳細ページでサイズと数量を選択して買い物カートへ商品を入れたい | |
| アクター | ユーザー | |
| 事前条件 | 商品の在庫がある | |
| サイズが複数ある | ||
|
事後条件 |
選択したサイズと数量の商品が買い物カートに入っている |
|
| 基本フロー | ステップ | アクション |
| 1 | サイズを選択する | |
| 2 | 選択したサイズの画面に更新され数量が1になる | |
| 3 | 数量を選択する | |
| 4 | カートへ入れるボタンをクリックする | |
| 代替フロー | ステップ | アクション |
| 3.1(a) | サイズを変更する | |
| 3.2(a) | ステップ2へ戻る | |
| 例外フロー | ステップ | アクション |
| 4.1(b) | 在庫がなくなる | |
| 4.2(b) | カートへ入れるボタンをクリックする | |
| 4.3(b) | 在庫がなくカートへ入れられなかったことをユーザーへ通知する | |
| 4.4(b) | 通知の確認ボタンをクリックする | |
| 4.5(b) | 売り切れの画面を表示する | |
| 補足 | 買い物カートに入れると在庫数量が減少する | |
ユースケース名
ユースケースの内容が一目で分かる名前を記載します。ユースケース図でも表示するため、「...する」のように簡潔に書くようにします。
ID
ユースケースを一意に決められるIDを記載します。組織やプロジェクト等の規則に従い管理できるIDにします。
目的
ユースケースを実行する目的を記載します。「...したい」、「...するため」のように書くのが一般的です。
アクター
ユースケースのテスト対象と相互作用するユーザーやシステムを記載します。
事前条件
ユースケースを実行する前に満たしておくべき条件を記載します。
事後条件
ユースケースを実行した後に満たすべき条件を記載します。
基本フロー
ユースケースの目的を達成するために、最も頻繁に実行されるシナリオのステップを列挙するように記載します。アクターが複数ある場合は、アクターを主語として明示し、アクターのアクションを記載します。
基本フローは、主要フローやメインストリーム（JSTQBの定義による）などとも呼ばれます。
代替フロー
基本フロー以外の事後条件を満たすことができる、シナリオのステップを列挙するように記載します。
基本フローから分岐する場合は、分岐が分かるようにステップ番号などを書きます。
例外フロー
事後条件を満たすことができないシナリオのステップを列挙するように記載します。
この記載方法の例では例外フローを区別して記載しましたが、区別せずに代替フローに含める記載方法もあります。
補足
フローに書ききれない詳細や非機能仕様など、テスト実行時の補足になる内容を記載します。
以上がユースケースの記述方法の例です。
ユースケースを俯瞰するためにユースケース図を用いたり、ユースケースの細部を補うためにシーケンス図（※3）やアクティビティ図（※4）を用いることもあります。
※3 シーケンス図
※4 アクティビティ図：いずれもUMLで使用される設計手法。
おわりに
- ユースケースとは、要求やシナリオの集合を扱いやすくしたツール
- ユースケーステストとは、ユースケースをテストベースとしたテスト設計技法
- ユースケーステストとシナリオテストには、網羅性などの違いがある
- ユースケースの記述方法の例示
ここまで、ユースケースとシナリオテストの違い、およびユースケースの記述方法について解説してきました。
シナリオを利用しながら要求や仕様を満たしていることを網羅的にテストしたい場合はユースケーステストが、経験やリスクなどからピンポイントのシナリオを作成してテストしたい場合にはシナリオテストがおすすめです。
