【ソフトウェアテスト】ユースケーステスト
ユースケース(use case)テストとは、システム開発要件や機能仕様などのテスト対象に対して利用者サイドから想定しうるテスト対象の使用状況や相互の作用をユースケースとしてシナリオを想定することで、対象の利用に際して問題がないかを主軸にしてテストを行う手法です。
シナリオを想定してテストを行うため、シナリオテストと混同されやすいですが、シナリオテストと比較してテスト対象や目的やテストの粒度など違う部分があるので、ユースケーステストとシナリオテストはそれぞれ別の手法として、実施するテストケースに応じて使い分けが必要です。
シナリオテストは主に特定の機能や操作の流れを一連のシナリオとしてテストするもので、対象となる仕様や要件のみならず、ストーリーとして関連が想定される動作や異常系処理などもテストスコープに含むため、ユーザーサイドの視点で対象に対して詳細なテストを実施しますが、ユースケーステストは、あくまで対象となる仕様や要件から想定されうるユーザーストーリーをテスト対象とする前提で、シナリオテストよりもテストスコープは狭くなると想定されます。
また、記事内にて後述しますが、ユースケース図を用いていることもユースケーステストの特徴であり、シナリオを順序立てる記述形式はシナリオテストもユースケーステストも同様ですが、テストケースの整理や共有の方法によってテストケース自体をレビューできるため、静的テストのアプローチがしやすいテスト技法です。
1. システム要件の一例
既に市場リリース済みのスマートフォン向けアプリケーションで、これまでアプリ内課金要素がなかったサービスですが、追加でアプリ内課金ができるシステムを開発し実装する想定とします。
1-1. 課金機能追加実装の要件
・アプリのトップページ内に課金機能画面への導線ボタンを追加する
・ユーザーの登録情報を照合して18歳以上なら、ボタンタップ後は課金機能画面へ遷移できる
・ユーザーの登録情報を照合して18歳未満なら、ボタンタップ後はサービス利用不可ダイアログを表示し、課金画面には遷移せずトップ画面に戻る
・ユーザー登録情報で18歳未満のユーザーについては、課金機能画面への導線ボタンの色を非アクティブな印象を与える色に変化させる(薄い灰色など)
・ユーザーはサービス利用開始時に必ず年齢登録を行っているものとする
2. ユースケース記述
上記の要件を元に、まずはユースケースを項目に分けて記述していきます。
ユースケース記述にはある程度定型があるようですが、いろいろな資料や解説を調べてみたところ、それぞれ微妙に存在する項目しない項目があったり、名称などが違っているところもあったので、いったん共通していそうな部分を統合して記載します。
・ユースケース記述の項目
ユースケース名：ユースケースを簡潔に表す名前
アクター：ユースケースに関わるユーザーや外部システム
事前条件：ユースケースが実行されるための前提条件
事後条件：ユースケースが完了した後の状態
基本フロー：ユースケースの正常な処理の流れ
代替フロー：基本フロー以外に別途フローがある場合
例外フロー：エラー発生時など、基本フロー・代替フロー以外の異常系処理の流れ
備考：各フロー以外に記載の必要な事項がある場合
ユースケース名：ユースケースを簡潔に表す名前で、何をどうする、等のようにユースケースの内容を明確に表現します。
例：「商品を購入する」「ユーザー登録する」
アクター：ユースケースに関わるユーザーや外部システムです。アクターとシステムや操作や動作フローがどのように関わるかがテストケースの主軸です。
事前条件：ユースケースが実行されるための前提条件がある場合は、当該項目に記載します。
事後条件：ユースケースが完了した後の状態を記載します。
基本フロー：ユースケースの正常系処理フローを、箇条書きの形式で具体的に操作手順を記載します。分岐やループ処理が想定される場合は、それも併せて記載して、処理の流れを明確にします。
代替フロー：基本フロー以外に想定されるフローがある場合は、代替フローとして記載します。異常系の別フローを記載することもあるようですが、それはそれで例外フローとして記載する場合もあるようです。
例外フロー：代替フローに異常系フローを記載する場合は、当該項目は不要ですが、基本フロー・代替フローが正常系だった場合は、想定される異常系フローがある場合は当該項目に記載します。
備考：各項目に記載しなかったことで別途追記が必要な事項がある場合は、当該項目に記載します。
開発要件を上記各項目に当てはめて、ユースケース記述形式で表したものが以下になります。
・ユースケース記述
3. ユースケース図
ユースケースの記述については上記のとおりですが、これをさらに図で表すことで、各アクターとそのほかの関係性を整理することができます。
UML（Unified Modeling Language：統一モデリング言語）は、QAやテストエンジニアのみならず開発に関わる方にはなじみのあるものかもしれませんが、システム開発の過程を図として表現するモデリング手法です。
ユースケース図もUMLに定義されたダイアグラムの一つです。
ユースケース図を構成する要素は主に以下のものです。
・アクター
主にシステムと関わる人や組織、外部のシステムなど
人型の記号を使用する
・ユースケース
アクターがシステムに対して実行できる一連のアクション
楕円形の記号を使用する
・サブジェクト（システム境界）
ユースケース図で表すシステムの範囲
四角形の枠線で囲む
・関連
アクターとユースケース、ユースケース同士の関係を表す
それぞれの要素を線でつなぐ
そのほか状況や内容に応じてリストやコンテナなどの表記を用いる場合がありますが、基本的に用いられるのは上記4点です。
これらを元にユースケース図を作っていきます。
アクターはサービス利用ユーザーです。
・サービス利用ユーザー
ユースケースはいったん以下としました。
・ログイン
・課金機能を使用
・ユーザーの年齢を判定
・課金画面を表示
・利用不可ダイアログを表示
サブジェクトはシンプルにシステムのみとしました
・システム
以上の内容を反映させたユースケース図が以下になります。
・ユースケース図
4. 追記
調査が不足しており、表記の規則などがあまりちゃんと把握できていません。
資料によっては点線を使用する場合と実線を使用する場合とがあったり、サブジェクト内でさらにパッケージを入れ子にする場合の枠をフォルダの形で表記したりフレームにタブが付いたような枠で表記したりという傾向が見られましたが、[アクター][ユースケース][サブジェクト][関連]は原則として、それ以外の内容や線と記号の用い方などはこれ以外は認めないという絶対の仕様は定まっていないように思いました。
また、ユースケースの粒度も資料によってさまざまあり、1つのユースケース図内で大きくぶれていない限りは、特に絶対という仕様はないように思えましたので、今回はこのようなユースケース図になりました。
<< include >>と<< extende >>についても今回の図で使用した方法が本来の用途かは確信がなく、もしかすると今回作成したユースケース図での用い方は適切ではない可能性がありますので、その点はお含みおきください。