シナリオテストとは？書き方や注意点を解説

シナリオテストとは、システム開発におけるテスト技法のひとつです。シナリオに則った手順で行う操作により、システムに不具合が起きないか、業務に問題はないかを確認する重要なテストでもあります。また、シナリオテストを実施することによって、開発者視点だけではなくユーザー視点での改善も可能になるでしょう。

本記事では、シナリオテストの概要と目的、シナリオの書き方を解説します。

シナリオテストとは、ユーザーが一連の流れに沿ってシステムを問題なく利用できることを確認するためのテストのことです。開発者の視点だけではなく、ユーザーがシステムを問題なく利用できることを目標に、ユーザー視点での確認がメインとなるテストです。そのため、システムテストや受け入れテストなどでこのテスト技法が用いられます。

なお、ISTQBの定義ではシナリオテストとユースケーステストは同義とされており、次のように定義されています。

シナリオテストにはさまざまなバリエーションがあります。詳細は「さまざまなシナリオテスト」の項目で説明します。

シナリオとは、映画やドラマなどで使われる脚本と同じように、開始から終了まで繋がった物語のようなものを指します。途中で場合分けが入ったりするものはひとつのシナリオにはなりません。場合分けをそれぞれテストしたい際には、複数のシナリオを用意してテストする必要があります。

システム開発においては、ユーザーが想定した利用手順に従って利用開始から終了までに想定される操作と流れ、およびそれによって期待される業務の進行やシステムの挙動を記したものです。シナリオテストの目的は、実際にシステムを利用することで業務としての要件が達成できているかを確認することです。

シナリオテストで確認する内容は業務要件レベルであることが多く、シナリオのインプットとなるドキュメントは業務フローを中心とした要件定義のドキュメントとなります。

通常の開発では、ある程度の数のシナリオを実行してシナリオテストを行います。あらゆる操作を想定したシナリオを用意して網羅的に調べることはできますが、非常に多くの工数がかかるためにすべてのシナリオでテストを実施するのは現実的ではありません。例外的な対応が必要になる事象も含めて、重要なシナリオを厳選してテストをすることになります。

一言でシナリオテストといっても、実際にはさまざまなシナリオテストが行われています。

最も代表的なシナリオテストは、システムを使うユーザーの立場から、業務の流れとの整合性を確認するテストになります。業務を時系列に捉えますが、そのごく一部をピックアップしてそこだけテストする場合もありますし、年単位のデータ蓄積をテストする場合もあります。ほかシステムとの連携や、システムと離れた作業を含めて確認することも一般的です。

実際にシステムを操作するユーザーは、実業務の担当者を呼ぶこともあれば、想定のユーザーに近いモデルユーザーを探すこともあります。特に一般公開されているようなシステムでは、さまざまな年齢や身体的特徴を想定して複数のユーザーを選ぶことがあります。システムの運用者もシステムのユーザーには変わりなく、さまざまな運用の業務が問題なく実施できることを確認します。

非機能テストにおいてもシナリオが重要になります。負荷テストやロングランテストでは、システムの利用状況を想定した複数のシナリオを、その利用のバランスに合わせてミックスしたシナリオを設計します。ユーザビリティテストでは、利用者の特徴、利用の目的、利用の状況を想定してシナリオを作成します。互換性テストでは、対象となる複数の環境で同じシナリオの操作ができることを確認します。

業務によっては、多くのシナリオテストを実施できない場合もあります。例えばお金のやり取りが発生したり、物理的な人の移動が発生したりするようなシナリオです。このような場合には、シナリオの一部を代替手段で置き換えたり、あるいは「やったこと」にしてテストを設計することも多くあります。

シナリオテストを行う場合には、誰が参加して何を確認すればいいのかというテストの目的を明確にして、適切なシナリオを検討するようにしましょう。

シナリオテストを用いる目的は、システムを使用するユーザー視点でシステムの動作の一連の流れを確認することです。いい換えれば、ユーザーが満足できる品質になっていることを保証するために行われるものです。

要件通りの機能を搭載していたとしても、必ずユーザーが満足してくれるとは限りません。シナリオテストはユーザー視点でテストを行うため、満足度の低下を招く問題を検出し、改善に結びつけることができるのです。ユーザーが運用する環境に近い状態でテストを実施することから、それ以前のテストでは発見できなかった問題の検出も期待できます。

まとめると、総合的に満足度が高いシステム開発につなげられること、リリース後の不具合を防止することが、シナリオテストの目的となります。

シナリオテストを実施することで、次のメリットを享受できます。

■メリット
・複数システム、複数画面含めた一連の流れで確認できる
・役割が異なる複数のユーザーが相互に連携する内容を確認できる
・一連の流れの中で機能間での不整合を検出することができる

システムのほとんどは、単一の画面で一連の流れを確認できるほど単純な構造をしていません。何かしらの条件をもとに、とあるデータの内容から異なる画面を表示したり、そもそも表示しなかったりと複雑になっているものばかりです。つまり、単一のテストだけでシステムに不具合がないかを判断することはできないことになります。

シナリオテストでは、異なるシナリオを実行する複数の仮想ユーザーがテストを実行することで、システムが要件通り動作するかを確認できます。また、複数のテスターが行ったテスト結果から、機能間での不具合や不整合を検出しやすくなるでしょう。シナリオテストを行うことで、異なる複数の結果から、不具合や仕様上の不備を発見できる確率が高まるのです。

また、機能は完全に作られていても、実際に利用者が使ってみると、使いにくかったり使うのにとても手間がかかったりすることがあります。こういった問題もシナリオテストを行うことで確認しておきましょう。

一方、以下のようなデメリットもあるため、シナリオテストの適用範囲は十分に検討する必要があります。

■デメリット
・細かいパターンまで網羅的に実施しようとすると膨大な工数が必要となる
・シナリオとして定義された内容以外の問題点を見つけ出しにくい

テストのパターンが複雑になる場合、膨大な量のシナリオを用意し、実行しなければならなくなります。システムの精度を高めるためには必要なことですが、反面、手間も時間もかかってしまうというデメリットがあることも覚えておく必要があるでしょう。

基本的には、ユーザーが使用するうえで重要となる流れのみシナリオを作成し、それを実施するのが現実的です。

業務的な例外事項が発生した時にシステムとして矛盾しないで処理できるかという観点も重要です。ただし、例外事項は考え始めると無数に想定できてしまうので、あえて代表的な例外事項に絞り込むのがよいと考えられます。

シナリオテストを作成する際の手順は、以下のとおりです。

■手順
1．アクターの洗い出し
2．シナリオ目的の洗い出し
3．シナリオの詳細化（スタートからゴールまでのステップを洗い出す）
4．確認項目と期待値の明確化

上記の手順で行うことで、質の高いシナリオテストが実行できるようになります。各工程で何を行うのか、詳しく見てみましょう。

シナリオテストに使用するシナリオを作成する前に、アクターの洗い出しを行わなければなりません。アクターとは、システムに何らかの役割をもって外部からアクセスする利用者やシステムのことです。一般的にはシステムを操作する人に加えて、連携するほかのシステムがアクターに該当します。

例えば、社内の経費申請システムで考えてみましょう。この場合、アクターとして、経費申請者や承認者などが考えられます。さらに、給与支払と併せて精算するような仕組みであれば、給与管理システムとの連携が発生するため給与管理システムという別システムもアクターとして必要になるかもしれません。

アクターは要件定義書から拾うことができますが、システム開発を依頼してきた顧客にもヒアリングしておきましょう。シナリオテストは、アクターが操作手順に従って使用した場合にシステムに不具合がないかを調べるテストであるため、アクター不在のままシナリオを作成することはできません。ステークホルダーにアクターは誰なのかを聞いておくようにしてください。

次に、シナリオの目的を洗い出します。目的とは、そのシナリオで何を達成したいかということです。目的を洗い出すとシナリオの範囲を決めることができます。

先にあげた社内経費申請システムの目的が「経費申請業務が成立すること」と仮定すると、次のようなシナリオが成立します。

1．社員が経費申請
2．何人かの上司が申請を承認
3．給与振込日に経費が振り込まれる

経費申請、承認、振り込みはシステムの一連の操作ではなく、別々のタイミングで行われます。そうなると、それぞれのタイミングでデータが連動しているかということを確認する、というシナリオの目的が見えてきます。また、月に複数の経費申請をしたらどうなるか、とか、上司が却下したらどうなるか、といったテストも考えられるでしょう。

シナリオ目的を洗い出し、明確にすることで、どのようなテストを行うということが明確になり、テスト結果に信頼性を付与することができるのです。

これもアクターの洗い出しと同様、ステークホルダーに対するヒアリングで明確にすることができます。開発者側で想定したシナリオ目的がすべてとは限らないため、顧客のもっているシナリオも参考にしてください。

シナリオの詳細化とは、シナリオ目的を条件や時系列で設定することです。詳細化するには、条件・時系列・優先度に分けてシナリオを設定するといいでしょう。また、同時に、操作中のユーザーの心理状態も想定してより詳細なシナリオを作成する方法もあります。

ステップとは、シナリオに含まれる業務プロセスのことで、どのアクターが何をするか（○○画面で、△△を行うなど）のことです。経費申請を例にあげると、「社員が経費申請システムの“経費入力”画面にて、○○年○○月分の経費項目を入力する」というのがひとつのステップになるといえます。

このステップをクリアしていく中で、ユーザーの心理や行動パターンを想定することで、ユーザーが抱えそうなニーズや想定できる行動を洗い出すことができるでしょう。顧客が抱えている要件や、過去の類似システムで起こった操作事例などを参考に、シナリオをより詳細なものにするのが理想的です。

最後に、各ステップにおける確認項目と期待値を洗い出します。確認項目とは、実際の操作や目視で確認できる項目のことで、期待値とは、操作の結果システムがどのように動作するかを表すものです。

このとき、モノが変化する箇所を洗い出すことがポイントです。一方画面操作や画面遷移は、テスト実行時の手順として必要になる部分ではありますが、シナリオテストで確認したいポイントではないため、確認項目には入りません。画面遷移などの個々の動作は機能テストで確認した後で、シナリオテストではユーザー視点の業務実施に着目して問題がないかを明確にすることが重要です。

これらを想定するには、テストすべき対象を明確にする必要があります。想定ユーザーの心理や行動を考慮し、どのような操作を行いどんな結果が得られるのかを書き出しましょう。

シナリオテストを作成する際、以下の点を注意する必要があります。

・確認項目や操作手順を細かくしすぎない
・実際の利用者にもレビューしてもらう

シナリオテストはシステムの不備がないかの確認のほか、ユーザーの満足度を向上させる目的で行われるテストです。確認事項は多いほうが不備は少なくなるものの、開発者側の負荷が重くなってしまうでしょう。また、あくまでもユーザー視点でテストはするものの、想定しているユーザーの感想と実際の感想が異なる場合があります。これらを踏まえたうえで上記2点を注意してシナリオテストを作成するようにしてください。

シナリオテストの場合、複数システム、複数画面を跨ぐシナリオになることが多くあります。そのため、確認項目や操作手順を細かくしすぎるとテスト準備の工数が膨大になる可能性があるでしょう。テスト実施者が迷わない程度の粒度で記載することをおすすめします。

確認項目は、主に次の3つにするとよいといわれています。

・情報の発生と受け取り
・データの更新と蓄積
・業務の進行と例外対応

可能であれば、実際にシステムを利用する利用者にテストシナリオをレビューしてもらえるといいかもしれません。いくらシナリオを想像しても、あくまで想像であるため限界があるのは事実です。また、シナリオのインプット資料としてユースケースや業務フローがあったとしても、実際の利用者がシナリオを確認することで不足点が見つかることも多いためです。

シナリオ完成後に利用者にレビューをしてもらうことで、よりテストをする製品の満足度を向上させることができるでしょう。レビューでなく、テスト実行のユーザーとして利用者が参加するのも有効です。可能であれば利用者の協力を要請しましょう。

シナリオテストを実施するには、考えるべきことやヒアリングする項目が多くあります。手間がかかるのは間違いありませんが、開発したシステムのユーザー満足度を高めるためには欠かせないテストです。仕様レベルの機能ではわからないことが明確になるテストであるため、ぜひ実施しましょう。

自社でシナリオテストを行うノウハウがない、他社に作ってもらった製品のシナリオテストを実施してほしいという方は、ぜひSHIFTまでご相談ください。SHIFTは、ソフトウェアテストで豊富な実績をもっており、シナリオテストのほかにも多くのテストの実施が可能です。システムテストなどのテストのみの実施も可能なほか、開発も対応しています。ソフトウェアテストのご用命やシステム開発でお困りの方は、SHIFTがお悩みを解決できるかもしれません。

参考文献

ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

ISTQBテスト技術者資格制度
Advanced Level シラバス 日本語版 テストマネージャ Version2012.J04
http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J04.pdf

ソフトウェアテスト標準用語集 日本語版 Version 3.2.J01
https://www.jstqb.jp/dl/JSTQB-glossary-introduction.V3.2.J01.pdf

IPA ソフトウェアテスト見積りガイドブック
https://www.ipa.go.jp/files/000005132.pdf

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座