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