WRブログ

ユースケーステスト

テストは全て、開発者とテスト担当者がおこなうと思われがちですが、それだと、どうしても視野が狭くなってしまいがちです。
そこで、テストの中にはユーザー目線でおこなうものも存在します。
ここでは、ユーザー視点に立って考えるユースケーステストについて解説します。
■ユースケースとは
ユースケーステストで使われるユースケースとは、アクター(ユーザーもしくはテスト対象とは別のシステム)と、テスト対象との間での相互作用を表現したものです。
ユースケースを使用するのは技術者や専門職の人間だけではないため、専門用語などはなるべく使わず、分かりやすい用語を用いると良いとされています。
また、ユースケースに記載される内容としては、アクターとテスト対象のシステムとの間の全てのやりとりを記載するのではなく、アクターにとって価値のある結果が得られるものを記載します。
■ユースケーステストとは
ユースケーステストとは、上記のユースケースをもとに、テストケースを設計していきます。
このとき、ユースケーステストで用いるのはユースケース図ではなく、ユースケース記述である点に注意してください。
ちなみに、ユースケース図とは、アクターとテスト対象となるシステムの関係を図で表しただけのものであり、
そこにアクターとテスト対象となるシステムとのやりとりは記載されません。
■ユースケース記述
ユースケース記述には、いくつかのフォーマットがあります。
ここでは、一般的なユースケース記述で使われるフォーマットをご紹介します。

■ユースケース名:
ユースケースの名前です。
ユースケースの内容が一目で分かる名前をつけましょう。

■目的:
今回のユースケースの目的を記載します。

■アクター:
ユースケーステストの対象と相互やりとりをするユーザー、もしくはテスト対象とは別のシステムを記載します。

■事前条件:
ユースケースを実行する前に満たしておかなければならない条件を記載します。

■事後条件:
ユースケースを実行した後で満たされなければならない条件を記載します。
メインストリームとも呼ばれます。

■基本フロー:
前述したユースケースの目的を達成するために、最も頻繁に実行されるシナリオのことです。

■代替フロー:
代替フローは、基本フロー以外のアクションをおこないますが、基本フローと同じ事後条件にならなければいけません。

■例外フロー:
例外フローは、アクションだけでなく、事後条件も基本フローと異なるシナリオのことです(代替フローと例外フローを区別せずに、代替フローとする場合もあります)。

基本フロー、代替フロー、例外フローを合わせたものを、プロセスフローと呼びます。
このプロセスフローの書き方には、自然言語で記述する方法や、一連の実行の遷移を記載したアクティビティ図を使う方法、フローチャートを使う方法などがあります。
■ユースケーステストのカバレッジ
ユースケーステストのカバレッジには、明確な記述はありません。
しかし、前述したプロセスフローをアクティビティ図に置き換えたりすることで、命令網羅とも呼ばれるステートメントカバレッジや、
プログラムの内部でおこなわれる判定条件を少なくとも1回はテストするデシジョンカバレッジと同じ考え方をすることができます。
★まとめ
●ユースケースとは、アクターと、テスト対象との間での相互作用を表現したもの
●ユースケーステストで用いるのはユースケース図ではなく、ユースケース記述
●ユースケース記述の書き方

ここまでで、ユースケーステストについて解説してきました。
テストの中でもユーザー側に立ったテストであるため、基本的にはソフトウェア開発の終盤でおこなわれます。


【参考文献】:
『ソフトウェアテスト教科書 JSTQB Foundation 第3版』

【参考URL】:
https://appkitbox.com/knowledge/test/20130912-134,(参照 2016年7月30日)
https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9,(参照 2016年7月30日)
https://www.ibm.com/developerworks/jp/rational/library/04/r-3217/,(参照 2016年7月30日)
http://www.itmedia.co.jp/im/articles/1111/07/news137.html,(参照 2016年7月30日)
http://www.itmedia.co.jp/im/articles/0404/08/news084.html,(参照 2016年7月30日)