シナリオテストとは? 結合テストとの違いや作成方法を解説
シナリオテストとは何か?
シナリオテストとは、ユーザーがソフトウェアをどのように利用するのかを想定し、ユーザーの視点でシステムが期待どおりに動作するかを確認するためのテスト技法です。システムの信頼性と利便性を向上させる重要な手法として、特にシステムテストや受け入れテストなどで活用されます。
シナリオテストは実際の運用状況下での動作や機能の正確性を評価し、システム上の不具合だけでなく、システム全体の一貫性やユーザビリティを確認する役割も担っています。また、あくまでユーザーが快適に利用できることを確認するのが主な目的であるため、シナリオテストではソフトウェアの内部構造には着目しないことに留意する必要があります。
シナリオとは
シナリオと聞くと、演劇や映画の筋書きを思い浮かべる方も多いのではないでしょうか。実際に演劇や映画は、台本や脚本などのシナリオに沿って物語が進行していきます。これはソフトウェア開発においても同じことがいえ、シナリオテストとは「開発者やテストエンジニアが考えた台本に沿って行うテスト」ともいえます。
ソフトウェア開発におけるシナリオとは、「ユーザーがシステムを利用する際、利用開始から終了までの一連の流れのなかで想定される行動や、その行動によって期待されるシステムの挙動などを記したもの」です。開始から終了までが一つのシナリオであり、途中で例外などの場合分けが必要なケースでは、別途シナリオを作成する必要があります。
シナリオテストの業務内容
シナリオテストの代表的な業務内容は、システムを操作する流れや業務との整合性を、実際にソフトウェアを使用するユーザーの立場から確認することです。ユーザー目線でユーザーの行動を想定してテストシナリオを作成するため、基本的には時系列に沿ってテストを実施していきます。また、単一の機能だけではなく、ほかのシステムとの連携やシステムと離れた作業を確認することも、シナリオテストの一環です。
実際のシナリオテストでは、仮想ユーザーとして実業務の担当者を選出することもあれば、想定したユーザーに近いモデルユーザーを起用することもあります。特に一般公開されているような利用者の幅が広いシステムのシナリオテストでは、年齢や身体的特徴を分散させるために複数のユーザーを選ぶ場合が多いです。
シナリオテストと結合テストの違い
シナリオテストのほか、ソフトウェアテストには「結合テスト」というものがありますが、この2つのテストはその目的が異なります。前述のとおり、シナリオテストはユーザーの視点でシステムが期待どおりに動作するかを確認し、ユーザー体験を評価するために行います。一方、結合テストは、個別に作成されたモジュールやコンポーネントなどを統合した後、それらが正しく連動して機能するかを確認するために行います。つまり、それぞれ別個に作成した部品を組み合わせた結果、仕様どおりに動作するかを確認する開発工程の一部だといえます。シナリオテストがシステム全体を評価することが主眼なのに対し、結合テストは各モジュール・コンポーネントが正しく統合されているかに比重が置かれているため、テスト観点も異なります。
シナリオテスト | 結合テスト | |
---|---|---|
テストの目的 | ユーザー視点で期待どおりに動作をするかを確認し、ユーザー体験を評価する | 異なるモジュールやコンポーネントが適切に連携し、正しく動作するかを確認する |
テストの焦点 | ユーザーが実際に行う操作手順に焦点を当て、システム全体の操作性を確認する | モジュール間のインターフェースやデータのやりとりに焦点を当てる |
タイミング | システムテストの一環として結合テスト後に実施することが多い | 通常は関連するモジュール・コンポーネントの単体テスト後に行う |
実施範囲 | システム全体を対象にユーザーの操作フローに沿ってテスト | 各モジュール・コンポーネント間の連携部分をテスト |
テストケース | 想定ユーザーの仕様パターンや業務フローに従ってシナリオを作成 | 各モジュール間のインターフェース仕様に基づいてテストケースを作成 |
さまざまなシナリオテスト
シナリオテストは、単体テストや結合テストのようなソフトウェアテストにおける工程の一部ではなく、あくまでテスト技法の一つです。そのため、各テスト工程においてシナリオテストは活用され、一口にシナリオテストと言ってもさまざまなシナリオテストが行われています。
上記の項目で述べた、時系列に沿ってシステムを操作する流れや業務との整合性を確認するテストのほか、負荷テストやユーザビリティテスト、互換性テストなど、機能以外の観点からチェックをする非機能テストにおいてもシナリオテストは活用されています。例えば、負荷テストではアクセス集中時における機能ごとの操作比率を想定してシナリオを作成したり、ユーザビリティテストでは利用者の特徴・利用目的・利用状況を想定してシナリオを作成したりします。
汎用性の高いシナリオテストですが、業務によってはシナリオの設計が難しい場合もあります。例えば、金銭のやりとりが発生するシナリオや、物理的に人の移動が発生するようなシナリオです。このような場合は不確定要素が多く、シナリオの設計が困難であるため、一部を代替手段へ変更するなどの対応が必要となります。
シナリオテストの主な目的
シナリオテストの主な目的は、「ユーザーが満足できる品質になっていることを保証すること」と、「ソフトウェアリリース後に不具合が見つかるリスクを低減させること」です。
ソフトウェア開発においては、たとえ要件通りに機能を実装しても、必ずユーザーが満足するという保証はありません。顧客満足度を上げるためには、ユーザー視点に立ち、ユーザーに寄り添った開発が求められます。シナリオテストはユーザーの利用を想定した上でテストを実施するため、満足度を低下させる問題を効率的に検出することが可能です。
また、実際にユーザーが利用する環境に近い状態でテストを実施することで、機能面に焦点を当てて行うテスト工程では発見が難しかった不具合を検出できます。このためシナリオテストは、リリース後に不具合が見つかることの防止にも大きく寄与しており、結果としてユーザー満足度の高いソフトウェアをリリースすることにつながっています。
シナリオテストのメリット
ユーザー満足度が高い高品質なソフトウェアを開発するためにも、シナリオテストは必ず実施すべきテストと言えます。シナリオテストにはさまざまなメリットがありますが、ここでは特に大きなメリットを2つご紹介します。
複数のシステムや画面にまたがる流れを確認しやすい
複数のシステムや画面間の横断を含めた複合的な一連の流れを確認しやすいことは、シナリオテストの大きなメリットです。
ほとんどのシステムは、何かしらの条件やデータを基に動作するため、複雑な構造になっています。そのため、単一の画面で一連の流れを確認したり、単一のテストだけで不具合がないことを判断したりするのは非常に難しいです。
シナリオテストはシナリオの流れに沿って総合的に確認を行うテストのため、一連の流れを確認しながら機能間の不具合を検出しやすいという特長があります。
仕様上の不備・不整合を発見しやすい
シナリオテストでは、役割の異なる複数の仮想ユーザーがテストを実施するため、多様なテスト結果のデータを得ることができます。その結果、相互に連携する機能やシステムの内容も確認でき、機能間の仕様上の不備や不整合を発見しやすくなることもシナリオテストの大きなメリットといえます。
ただし、仕様上の不備・不整合がなくても、ユーザー側からすると使いづらいソフトウェアになっている可能性も捨てきれないため、ユーザー目線を中心に考えたシナリオを設計することが大切です。
シナリオテストのデメリット
実施するメリットが大きいシナリオテストですが、一方でシナリオの作成に手間がかかるなどのデメリットも存在します。効率的にシナリオテストを進めるためにも、以下の2点を考慮した上でテストの適用範囲を決めていく必要があります。
網羅的に行うには工数と手間がかかる
シナリオテストは、ユーザーの利用を想定したシナリオに沿ってテストを行える反面、シナリオを一つひとつ考えなければならないという手間が発生します。従って、仮にシナリオテストを網羅的に実施しようと考えると、膨大な量のシナリオを用意しなければならなくなり、工数を圧迫する要因になってしまいます。
高品質なソフトウェアを開発するため、網羅的にテストを実施するという考え方は非常に大切です。しかし、シナリオテストにおいては、ユーザーが使用する上で重要な部分のシナリオのみを作成し、テストを実行していくのが現実的といえます。
あらかじめ定義されたもの以外の問題点を発見しづらい
もう一つのデメリットとして、あらかじめ定義されたもの以外の問題点を発見しづらいことが挙げられます。シナリオテストのシナリオは開始から終了までが一つのシナリオであり、途中でシナリオが分岐したり、場合分けが入ったりすることはありません。そのため、シナリオから外れた突発的な要素が入った際などに問題点を検出しづらいという側面が存在します。
こうしたデメリットをカバーするため、シナリオテストでは例外的な要素を考慮したシナリオも作成しなければなりません。しかし、想定できる例外事項は無数にあり、網羅的にシナリオを考えるのは難しいのが実情です。そのため、例外となるケースのシナリオを作成する場合においても、通常のシナリオと同様、代表的なものに絞り込んで作成するのがよいといえます。
シナリオテストの作成手順
これまでシナリオテストの概要をご紹介してきましたが、ここからは実際にシナリオテストを作成する手順をご紹介します。以下の手順で作成することで、質の高いシナリオテストを実施することが可能です。
①アクターを洗い出す
シナリオテストを作成する際、最初に行わなければならないのがアクターの洗い出しです。アクターとは、役割を持って外部からシステムにアクセスするもののことで、一般的にはシステムを利用する人や連携しているほかのシステムのことを指します。
ECサイトを具体例として挙げるのであれば、「Webサイトを通して買い物をする人」「商品を販売する企業や個人」「外部の決済システムを使用している場合はその決済システム」などがアクターとして抽出できます。
テストを行うシステムによって、洗い出すべきアクターの範囲は変わってきます。アクターの洗い出しには、要件定義書を確認するのはもちろんのこと、システム開発を依頼してきた顧客に直接ヒアリングするのも有効です。仮にアクターの洗い出しに漏れがあると、シナリオテストを正しく行えない可能性が高いため、この工程で入念に確認する必要があります。
②目的を設定する
アクターの洗い出しを終えた後は、そのシナリオテストで何を達成したいのかという目的を設定します。目的を設定することで、シナリオを作成する範囲がおのずと決まっていきます。
先ほど具体例として挙げたECサイトの目的が「Webサイトを通して商品を販売すること」である場合、以下のようなシナリオが考えられます。
- ECサイトに企業や個人が商品を出品する
- Webサイト訪問者が欲しい商品を検索してカートに入れる
- 決済情報を入力して購入が完了した後、商品が発送される
このシナリオで注意すべきことは、商品の「出品」「購入」「発送」は一連の操作ではなく、別々のタイミングで実施されるということです。つまり、ECサイトの目的を達成するために、「各タイミングにおいて、データの連動が正確に行われているかを確認する」ことを、シナリオの目的として設定する必要があります。ほかにも、「商品の欠品時はどうするのか」や「決済情報が正しくない場合はどうするのか」などの確認を目的に設定することも考えられます。
また、シナリオの目的は、開発者側で想定されるものがすべてとは言い切れないため、アクターの洗い出し同様、顧客へのヒアリングを実施することが重要です。
③シナリオの詳細を作成する
次に、前の工程で決めたシナリオの目的を詳細化していきます。後述しますが、シナリオの詳細は「時系列」「条件別」「優先度別」を意識して作成するのがコツです。また、ユーザーの心理状態を想定することで、より詳細なシナリオを作成することができます。
前工程である目的設定との違いとして、詳細を作成する際には具体的な業務プロセスを盛り込まなければならない点が挙げられます。業務プロセスとは、どのアクターが何をするのかを表す要素です。ECサイトを例に挙げると、「Webサイトの訪問者が人気ランキング1位の商品を3点カートに入れる」というのが一つの業務プロセスになります。
このように具体的な業務プロセスを考えることで、ユーザーの心理状況や行動をより想定しやすくなります。ユーザーのニーズや行動を洗い出すほか、顧客へのヒアリングや過去の類似システムの事例などを参考にすることで、詳細なシナリオを作成できます。
④確認項目や期待値を書き出す
最後に、各業務プロセスにおいての確認項目や期待値を書き出します。確認項目とは実際に行う操作や目視による確認が可能な項目のことで、期待値は操作の結果としてシステムがどのように動作するのかを表したものです。
確認項目や期待値を書き出す際は、何かしらの行動や操作をすると状況や状態が変化する箇所を洗い出すことが重要です。ただし画面操作や画面遷移などは、すでに個々の動作を機能テストで確認しているため、シナリオテスト時の確認項目には含めない点に注意が必要です。
すでにご紹介している通り、シナリオテストではユーザー視点の業務に着目し、ユーザーの観点からシステムに問題がないかを確認することが重要です。テストすべき対象を明確にし、想定されるユーザーの心理状況や行動を考慮した上で、システムに対してどのような操作が行われ、どのような結果が得られるのかを書き出していきます。
シナリオテストの作成のコツ
シナリオテストでは、「時系列」「条件別」「優先度別」を意識してシナリオを作成することが重要です。先述したように、シナリオテストはユーザーの視点で行うテストです。ユーザーが実際に行う処理の流れを想定し、時系列に沿ってシナリオを作成することが大前提といえます。
また、シナリオテストには前提条件やシナリオの数に制約がありません。テスト結果を取りまとめやすくするためには、シナリオを条件別に設定し、テスト実施後の分析やレポートを整理できるようにすることが大切です。
さらに、テストのシナリオは無限に作成することができますが、スケジュールや人的コストには限界があります。システムが提供する価値の中から重要なものを取捨選択し、シナリオに優先順位をつけるのがお勧めです。
シナリオテストを作成する際の注意点
シナリオテストはユーザーの満足度を向上させるため、ソフトウェア開発において必要不可欠なテストです。しかし、シナリオ数が多くなり開発者の負担が増えてしまうといった問題や、想定しているユーザーの行動と実際の行動に相違が生まれるといった問題が起こり得ます。そのため、シナリオテストを作成する際には以下の点に注意が必要です。
確認事項や手順を細かく設定しすぎない
シナリオの粒度を適切に設定することが、シナリオテストを成功させるためのポイントです。シナリオを細かく設定しすぎてしまうと、確認事項や手順などの記載内容が増え、テストケースを作成する負担が増大します。また、テストを実施する際にも多くの情報をインプットする必要があり、テスト実施者の負担も大きくなってしまいます。
確認事項は「情報の発生と受け取り」「データの更新と蓄積」「業務の進行と例外対応」の3つにまとめるのがよいとされています。細かく設定しすぎるとさまざまな負担が増えるのは上述の通りですが、反対に大まかすぎても問題を特定しづらくなるため、バランスを取りながら適切に粒度を設定することが重要です。
利用者からも意見を聞く
いくらユーザーの行動を想定してシナリオを作成しても、実際にユーザーが取る行動と懸け離れてしまう可能性があります。そうした問題を解決するには、シナリオ作成後に利用者からレビューをもらうのが有効です。実際にソフトウェアを使用するユーザーから意見を聞くことで、ユーザーの行動とシナリオとの相違点を洗い出すことができ、よりユーザーの視点に立ったシナリオを作成することが可能になります。
また、意見を聞くだけでなく、実際のシナリオテストにユーザーとして利用者に参加してもらう方法もあります。利用者に積極的に協力を要請することで、シナリオテストの質が向上し、より顧客満足度の高いソフトウェアを開発することができます。
まとめ
シナリオテストは、ユーザー満足度の高いソフトウェアを開発するため、避けては通れないテストの一つです。しかし、ユーザーの行動を詳細に想定しなければならないほか、シナリオを数多く作成しなければならないなど、手間がかかる工程でもあります。
Sky株式会社は、ソフトウェア評価・テストに関する業務全般に対応しています。シナリオテストにお困りの際は、ぜひSky株式会社までご相談ください。