システム開発をする際には、品質を保証するために様々なテストを実施します。
機能に不具合がないかを確認することは、テストにおいて大切な要素です。それと同時に、ユーザーがシステムを不満なく利用できるかも確認する必要があります。
今回は、テスト手法のひとつであるシナリオテストについて、設計のコツと実施時の注意点を踏まえてご紹介します。
シナリオテストとは?
シナリオテスト = 実業務で行う操作を想定したテスト
シナリオテストとは、ユーザーが実業務で行う操作を想定したテストシナリオを作成し、工程毎の目的を正しく達成出来るかどうかを検証するテストです。ユーザーがシステムを利用して、タスクをスムーズに行うことができるかを検証するテストのため、システムの内部構造までは考慮しません。
例えば、データベースからとある部品の在庫を検索してくる処理をテストする場合は、検索時の内部処理は考慮せず、検索条件に対象部品の情報を入力後に検索ボタンを押して、正しい検索結果が表示されるかだけを確認します。
シナリオテストを実行することで、システムの内部処理の不具合だけではなく、ユーザーの実際の使用例に基づいて不具合や改善点を発見できるというメリットがあります。このような、仕様が満たせているかのみを確認するテスト技法はブラックボックステストとも呼ばれています。

ブラックボックステストについては、こちらの結合テストの記事でも詳しく紹介しているのでぜひご確認ください。
そもそもシナリオとは?
シナリオとは脚本のことであり、一つの流れでつながったようなもののことを差し、映画などで使われる脚本と似ています。そのため、途中で場合分けを入れるとシナリオにはなりません。例えば1度場合分けを入れるのであれば、2つのシナリオを準備する必要があります。
業務フローやユースケースの図、記述などがシナリオにインプットするためのドキュメントになります。
シナリオテストとユースケーステストの違い
シナリオテストと似たテストに、ユースケーステストがあります。
ユースケースとは、対象システムとアクター(対象システムを利用するユーザーや関係してくる別のシステムを意味します)との間の相互利用を表現したものです。アクターの目的や要求に照らし合わせたシナリオを基に設計されるのがユースケーステストです。
ユースケーステスト = アクターの要求に照らし合わせたシナリオ
シナリオテスト = ユーザーの実業務に合わせたシナリオ
一方シナリオテストは、ユーザーの実業務のシナリオをベースに設計されます。
ユースケーステストには、シナリオテストにはない網羅性があり、シナリオテストでは、ユースケーステストより自由度の高いテスト設計が可能です。
ユースケーステストにも実業務のシナリオが含まれている場合があるため、シナリオテストと混同されがちですが、それぞれの利点は異なります。また、シナリオテストとユースケーステストは、ともにユーザー目線のテストとなるため、第三者検証として専門の企業へテストを依頼するケースも多いです。
第三者検証については、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
シナリオテストを実施するメリットとデメリット

シナリオテストは、ユーザーが動作をする一連の流れがスムーズに進むかどうかを確認することが目的です。しかし、シナリオテストにはメリットやデメリットがあるため、それぞれ理解をしておくことが重要です。
メリット
シナリオテストのメリットとしては、複数画面であっても一度の流れでのテストが可能です。さらに、さまざまな役割を持つユーザーがそれぞれ連携する内容や機能面においての不整合の確認もできます。
デメリット
シナリオテストはあくまでシナリオとして定義された内容に対するテストです。
そのため、定義されていない内容であれば、問題の把握はむずかしい点が挙げられます。さらに、細かく網羅的にテストを実施する場合は、プロセスが増えその分手間がかかります。
シナリオテストの設計手順とは?
シナリオテストの基本的な設計手順は、以下のようになります。

1. アクターの洗い出しをする
アクターとは、対象システムを利用するユーザーや関係する別のシステムのことを意味します。
アクターを洗い出すことで、アクターがシステムにどのように干渉してくるのか、そしてシステムを利用することで達成できる目標は何かを整理出来るため、設計すべきテスト項目が明確になります。
2. 設計・実施の目的や前提条件を明確にする
テストの設計・実施の目的や前提条件を明確にします。目的や前提条件を明確にすることで、ユーザーのシステム利用パターンなどが想像しやすくなり、設計者ごとのテスト設計における考え方の相違を防ぐことが出来ます。
その結果、テストの設計者によってテストの粒度が異なったり、設計やレビューに掛かる時間に大きく差があるなどの問題を解消することが出来ます。
3. シナリオの詳細化を行う
目的を明確にした後は、シナリオの詳細化を行います。
詳細化とは、具体的にスタートからゴールまでのステップを洗い出すことです。ステップとは業務プロセスのことで、どのアクターが何を行うのかを指します。
例えば、「ユーザーが部品の在庫情報を検索する画面で、検索対象部品の情報を入力して検索ボタンを押下する」という作業の流れが1つのステップと言えます。
4. 確認項目を作成する
ステップを洗い出して詳細化を行なった後は、確認項目を作成します。
確認項目は、ユーザーがシステムを利用した際の出力結果が期待値通りとなっているか、データの登録や値が変化する箇所を洗い出して作成していきます。テスト内容を考える際、ユーザーの目的達成の妨げとなる事象についても洗い出すことが重要となります。
複数の組み合わせが発生するテストの場合は、あらかじめ対応表を作ってからテストを行うことで、抜け漏れがなく、効率の良い作業が行えます。
シナリオテスト設計・実施時のコツと注意点
続いて、シナリオテストを設計・実施する際のコツと注意点についてご紹介します。コツをおさえれば、様々な操作パターンに対応したテストシナリオを作成することが出来ます。
実際の利用者にもフィードバックをもらう
設計後は、システムを本番で利用することになるユーザーにもテストのシナリオを確認してもらい、フィードバックをもらいましょう。設計段階でテストシナリオの詳細化をしていても、ユーザーに確認してもらうことで、設計の不足点が見つかることも多くあります。
また、テスト工程としては、シナリオテストのあとに、ユーザにシステムを実業務と同様に利用してもらい動作検証をする「受け入れテスト」が控えていることが多いです。
受け入れテストについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
テストを網羅的に行う
シナリオテストでは、網羅的なテストを行いましょう。業務の時系列やフローから、様々な組み合わせを網羅することに加えて、クライアントとの要求仕様を満たしているかも考慮する必要があります。
また、正常時の想定しやすい動作や、機能単体のみのシナリオだと、想定外の動作により発生する不具合を発見できません。ユーザーは想定通りの手順では操作しないことも考えられるため、様々な操作パターンを網羅的にテストする必要があります。
確認項目や操作手順を綿密にしすぎない
シナリオテストは実業務に沿ったテストになる場合が多いため、確認項目や操作手順が複雑になりすぎるとテストの準備・及び実施に掛かる工数が膨大になってしまいます。
特に、テストの設計者と実施者が違う場合は、実施者が手順を見ても大きく迷わない程度の粒度で手順書を作成するとよいでしょう。
シナリオテストでよくある3つの質問

シナリオテストでよくある次の質問をまとめました。
- テストケースにおける粒度はどのくらいが適正ですか?
- シナリオテストの主な目的は何ですか?
- シナリオテストの自動化は可能ですか?
質問1.テストケースにおける粒度はどのくらいが適正ですか?
テストケースにおける粒度は、状況に応じて調整するようにしましょう。例えば細かい粒度に設定すると、時間が足りなくなる場合があります。そのため、テストの対象となる物によって合わせることが重要です。
質問2.シナリオテストの主な目的は何ですか?
シナリオテストは、予定通りに機能が動作をするかだけでなく、ユーザビリティが高いかどうかの確認が目的です。そのため、シナリオテストをする時ユーザーがどのように感じるのか、どのような行動をするのかを想定するようにしましょう。
質問3.シナリオテストの自動化は可能ですか?
シナリオテストを自動化することは可能です。毎回コマンドを入力することをはじめ、手作業でおこなうには手間がかかるプロセスがあります。しかし、自動化することで手間やヒューマンエラーが減らせます。
シナリオテストをしっかりと実施できるようにしよう

シナリオテストは、実業務に沿ったシナリオを基に行われるため、開発の最終段階として重要なテストになります。自由度の高いテストなので、様々な観点から網羅的なテストケースを作成して、不具合がないかを確認していきましょう。
シナリオテストを通じて、ユーザーの満足度向上の手がかりを見つけ出すこともできるため、設計時のコツや実施時の注意点についてよく理解して、シナリオテストをしっかりと実施できるようにしましょう。