【具体例あり】テストシナリオ作成方法！初めて作成する人必見！

本日はDXをテーマに、システム導入の終盤で登場するテストシナリオの作成方法を扱います。
私が過去のコンサルティングで実際に携わった事例をベースに記載している為、これからテストシナリオ作成に取り組むので概要を知りたいという方に、参考になるかと思います。

なお私もシステム導入に携わる際に活用しましたが、テストシナリオをはじめ、システム導入の全体感や包括的にポイントを把握したい方は以下書籍が参考になりますので、是非活用してみてください。

それでは一緒に見ていきましょう。

テストシナリオとは何か？

新たにシステムを導入する際は、そのシステムの品質を担保する為に、いくつかのテストを実施した後に実務で使用を開始します。
そしてそれらのテストの最終段階では、現場ユーザーがその新システムを用いて業務を問題なく遂行することができるかどうかをテストします。
この最終段階のテストを”ユーザー受入テスト（＝UAT）”と呼び、UATで業務の遂行可否をテストする際の前提となる業務の流れを記述したドキュメントが、テストシナリオです。（※UATの概要は次章参照）

テストシナリオ作成時に特に初心者が間違えやすいことの1つとして、新システムの個々の機能に対するテスト項目や期待される動作をテストシナリオに羅列していくことが挙げられます。
しかし、それは機能テストを行うためのテストケースに記述する内容であり、テストシナリオに記述すべき内容ではありません。
テストシナリオはUATを行う際の業務手順という位置づけなので、個々の機能を列挙するのではなく、一連の具体的な業務内容を記述するということを、まずは頭に入れましょう。

またシステム導入プロジェクトでは、テストシナリオを誰が作成するか？ということも、よく論点に挙がることの1つです。
テストケースであれば具体的な機能をテストするため、プロジェクトチームの中でもシステム開発を担当するチームが作成します。
一方でテストシナリオでは、上述のとおり一連の業務の流れを記述するため、その作成には業務に関する知識が必要になります。
従って、テストシナリオはシステム開発を担当するチームではなく、業務検討を担当するチームが作成します。

UATとは何か？

前章でUATについて触れましたので、UATの概要についても見ていきましょう。
UATとは、”User Acceptance Test”の略称で、ユーザー受入テストとも呼ばれます。

前章でも少し述べましたが、UATの目的を平たく言うと、新システムを用いて、問題なく業務を遂行することができるかをチェックすることです。
もう少し専門的に言うと、新システムの開発・導入は以下のV字モデルに則って進めることが多く、UATでは上流工程で定義したユーザー要件を新システムが十分に満たしており、業務に適した形で機能することを検証する為に実施します。

従ってUATにおける新システムの検証は、システム開発を担当するチーム（IT部門やシステムベンダー等）に任せるのでなく、実際にシステムを用いて業務を行う現場のユーザーが実施することが必要です。

また、新システムで業務が遂行できる状態とするには、新システムがユーザー要件を満たして適切に機能することだけでなく、ユーザーが新システムの操作に慣れた状態になっていることや、新システムからアウトプットされる各データの信頼性が担保された状態になっていることも重要です。

従って、UAT期間中にユーザーが新システムをいつでも操作できるようにすることでユーザーの習熟度を向上したり、アウトプットされたデータを確認することでデータの信頼性を検証したりすることも、UATの一環として行います。

テストシナリオの構成

ではテストシナリオの具体的な構成を、フォーマットのサンプルも交えて見ていきましょう。
テストシナリオはフォーマットの自由度が高いので、ここで紹介する内容を一つの参考とし、必要・不要な要素を取捨選択して、自身が関与するUATに適した構成にアレンジして頂ければと思います。

１．前提

テストシナリオには一連の業務の流れを記述していきますが、個々の業務をただ列挙しているだけでは、テスト実施者側は具体的な場面をイメージし難いでしょう。
従って、まずは冒頭にテストシナリオの前提となる場面や条件等を記述します。

２．テストシナリオ

実際に実務で行う業務内容をもとに、UATを行う上での一連の業務の流れを記述します。
業務の内容が幾つかに分類できる場合は、その分類も記述しておくと分かりやすいです。

３．対象システム

例えば大規模システムのUATでは、テストシナリオの一連の業務において、複数のシステムやモジュール（あるいはサブモジュール）の操作が生じる場合があります。
従い、各業務を行う際の対象となるシステムやモジュール等を記述します。（単一のシステムやモジュールのみであれば、この項目は不要です）

４．操作手順

テストを実施するユーザーが、新システムをどのように操作するかを把握できるよう、テストシナリオで挙げた個々の業務毎に、新システムの具体的な操作手順を記述します。
システムの操作が不要な業務の場合は、”ー”と記載するなどにより、システム操作が生じないことが分かるようにします。

５．テスト結果

ユーザーが新システムをテストした結果を記述します。
テスト結果は、〇・△・×やOK・NGなどの選択肢を用いて判定します。
なお、ユーザーによって解釈の違いが生じないよう、各選択肢の定義も明確にします。
例えば〇・△・×の場合は、
　〇：業務上支障無し
　△：業務に支障はないが改善を希望
　×：業務に支障があるため改善が必要
などのイメージです。
また特に△や×など、システムの改善が必要な場合、改善すべき内容をシステム開発者側が具体的に把握できるようにする為、ユーザーのコメントも記載します。

６．１から５を踏まえたサンプル

１から５をもとにしたサンプルイメージは以下のとおりです。

UATで生じた課題対応に関するポイント

新システムのテストを実施すると、様々な課題が生じます。
UATも同様であり、UATによってテスト実施者であるユーザーから挙げられた課題に、適切に対応することが必要です。
最後に、UATで生じた課題対応におけるポイントについても見ていきましょう。

１．課題を可視化する

テスト実施者である現場ユーザーからの回答内容を踏まえて、課題と判断される内容を抽出します。
また抽出した課題を課題管理表に転記して管理することで、課題の内容・規模感・対応状況等を可視化し、関係者が課題の状況を適宜確認できるようにします。
なお課題管理表については以下記事で解説しているので、詳しく知りたい方は、こちらをご覧ください。

プロジェクトを成功に導く！課題管理表の作り方と運用方法

業務改革やシステム導入、製品開発をはじめとした各種プロジェクトでは、プロジェクトの着手から完了まで予定通りに進捗することは稀で、通常はプロジェクトの過程でその進捗を阻む多くの課題が発生します。従ってプロジェクトを推進していくには、適切に課題...

skill-and-career-net.com

2023.08.30

２．カットオーバーまでに対応する課題/対応しない課題を選別する

UATで生じた課題は、新システムのカットオーバーまでに全て対応を完了することが理想ですが、時間やリソース等の制約もあり、現実的には難しい場合が多いです。
ただ課題によって実務への影響度は異なり、適切な処置を施さないと業務に支障が生じる課題もあれば、業務への支障はない（あるいは軽微な）課題もあります。
従って、課題の性質を踏まえて、カットオーバーまでに対応の完了が必要な課題と、カットオーバー後での対応で問題ない課題に選別し、カットオーバーに向けては、前者の課題対応に注力します。

３．本当に対応すべき課題か見極める

上記２の課題選別も然ることながら、そもそもユーザーから挙げられた課題の全てに対応すべきか否かということも見極めることが必要です。
UATではユーザーから様々な課題が挙げられ、その全てに対応することが理想ではあります。
しかし課題の中には、対応に要する工数や費用に対して効果が小さい課題や、特定の個人のみしか感じないような課題なども混ざっている場合が多いです。
従い、必ず全ての課題に対応するというのではなく、予算・リソース・システム仕様の制約等も踏まえ、どの課題は対応して、どの課題は諦めるなど、対応する課題の線引きをすることも重要です。

　

この記事で紹介する内容は以上です。
少しでも参考になれば幸いです。