2023.06.30

シナリオテストとは？業務をどうやって分解していくの？

Introduction

「シナリオテスト」は、「ユーザーが一連の流れに沿ってシステムを問題なく利用できることを確認するためのテスト」となります。JSTQBの定義では、「ブラックボックステストのテスト技法の１つで、ユースケースの動作を実行するようにテストケースを設計する」とされています。

業務を想定したシナリオに基づいて実施するテストでは、お客さまが行う業務が実現できるか、などの要求と合致していることを確認します。しかし、いざシナリオテストを実施しようとすると、要件定義書や業務フロー図があっても、そこからシナリオテストにどのように組み替えていけば良いのか、どこから手をつけていけば良いのか悩む方も多いと思います。

本コラムでは、業務を想定したシナリオテストを行う際に、業務を分解し、テストケースを作成するプロセスやポイントについて解説します。

業務を想定した「シナリオテスト」とは

業務プロセスの中のシナリオをテストすることで、業務を行う際に起こりうるシステムの不具合を発見することを目的としています。ユースケース図や業務フロー(アクティビティ)図等で表された一連の作業の「振る舞い」を、定義された順番や判断に従って実行します。そして、個々のプロセスや流れが実現可能かどうか、実際の業務が正しく行えるのかを確認します。また、ユーザーが業務で行う手順を考慮することで、ユーザー視点でのテストを実施することが可能です。

実施タイミングとしては、機能単体のテストや機能の内部結合テストが完了した後になります。実際のユーザーを交えて実施することもあります。

業務をどのように実施可能なテストケースまで分解していくのか

SHIFTの業務シナリオテストの設計では、以下のように要素分解をします。

	要素	説明
1	業務プロセス	業務の中で一連の作業の開始から最後までを処理する単位(ユースケース)で定義する。例：通常出荷、返品出荷　等
2	シナリオ	テストを実施する際の流れ、同一の業務プロセス内で作業内容や順序が分岐されている場合は、別シナリオとして定義する。例：通常出荷時点で欠品、ピッキング時点で欠品　等
3	パターン	同一のシナリオ内で結果が異なる場合に、パターンとして因子・水準の組み合わせを定義する。例：配送業者別に依頼票の出力形式が異なる場合因子：配送業者、水準：A社、B社、C社　等
4	手順	パターン内で行う作業について開始から終了までのやり方を並べる例：注文データを確認する、出荷指示をする　等
5	テストケース	シナリオ内で確認すべきポイントをテストケースとして定義する。テスト観点と関連付けて確認すべきポイントに具体的な期待結果を設ける。期待結果の数がテストケース数となる。

表 1　シナリオテストにおける要素分解

業務プロセスからシナリオテストを作成する6つのステップ

以下の6つのステップでシナリオテストのケースを作成していきます。

①業務プロセス分解

テストシナリオは最初から最後まで順番に実行していくものになります。そのため、業務フローを分解し、分岐の無い１本ずつのシナリオにしていきます。

以下の図２の例では、「通常出荷」という業務プロセスが業務フローで表現されています。この場合、お客様から受けた注文に対して、お客様が商品を受領するまでの流れを1本目のシナリオにします。次に、分岐部分に着目してシナリオを分解します。出荷時点の引当でNGになった場合を2本目のシナリオとし、ピッキング時にＮＧになった場合を3本目にするというように分解していきます。このように分解して、テストに必要なシナリオを決定します。

この作業を実施することにより、分岐はどこにあるのか、分岐条件にはどのようなものがあるのかということを整理していきます。1本にしたシナリオが長い場合は、途中で切りわけることもあわせて実施していきます。

②シナリオ整理

①で分解したシナリオを整理するために、1本のプロセスにまとめます。その際に、シナリオ内の各工程の分岐となる箇所を明確にし、分岐条件となる因子・水準を具体的に精査していきます。

また、集約する際には、シナリオの共通となる部分を確認します。なぜなら、分岐した業務プロセスのシナリオは、特定の箇所を除き、同じ工程を辿ることが多いからです。図3の例のように、集約したシナリオの横に、分解した3シナリオを並べ、実施対象に「●」をしています。「注文」から「指示受領」までの4工程は3つのシナリオで共通となっています。このように、共通部分を明確にすることによって、テストケースの複製が可能になり、テストケースの流用やカスタマイズがしやすくなります。

③テスト観点の検討

シナリオ中にどういった内容を確認すべきか、テスト観点を検討し、一覧にまとめます。

テスト観点を検討する際には、期待される機能や業務の要件を把握することが重要です。そのためには、①、②で作成したシナリオの範囲に限定せずに「ユーザーはシステムに何を期待しているのか」、「この業務は何を実現すると完了するのか」と考えていきます。
例えば、「顧客が商品を受領した際に、納品書の注文内容・数量が発注書と一致しているかどうかを確認する」テストをする場合、テスト観点に「納品情報出力」などとあげていきます。

テスト観点の検討段階から有識者やユーザーと話し合うことはとても有効です。
有効なテスト観点をあげられるだけでなく、テストケースを作ってからユーザーとの認識の相違に気が付くといった手戻りを防ぐことができます。

④シナリオと観点紐づけ

③で挙げたテスト観点を①②で整理したシナリオに紐づけていきます。表2のようにマトリクス状にしておくことにより、確認すべき観点の対応が明確になり、全体を俯瞰しやすくなります。

NO	テスト観点	説明	➊通常出荷	❷出荷指示時点で欠品	❸ピッキング時に欠品
1	配送情報入力	入力した配送情報に対してマスターに応じたチェックがされているかを確認する	〇	〇	〇
2	出庫情報登録	複数の出庫情報、かつ複数の配送情報が登録されていることを確認する	〇	〇	〇
3	出庫情報印刷	複数の出庫情報、かつ複数の配送情報が印刷されていることを確認する	〇	–	–
4	配送業者別印刷	配送業者に応じた、印刷フォーマットで印刷されていることを確認する	〇	–	–
5	納品情報出力	納品書の注文内容・数量が発注書と一致しているかどうかを確認する	〇	–	–
6	・・・	・・・	–	–	–

表 2　シナリオとテスト観点との紐づけ対応表

⑤パターンの洗い出し

④で紐づけられた、テスト観点を確認するためのパターンとなる因子・水準の組み合わせを決定します。②では分岐条件となる因子・水準を精査しましたが、ここでは、同一のシナリオ内で結果が異なる場合を考慮し、確認が必要なパターンを洗い出していきます。

例えば、「①通常出荷」のシナリオで「配送業者別印刷(配送業者別に依頼用の書類の印刷フォーマットが異なる場合)」というテスト観点を確認しようとした場合、因子は「配送業者」、水準は「A社、B社、C社･･･」などとし、シナリオ内で確認すべきパターンを洗い出していきます。

⑥テストケースに展開

②で整理したシナリオの工程ごとに、実際に手を動かす手順と具体的な期待値を記入して、テストケースに落とし込んでいきます。

※SHIFTでは、SQF(SHIFT Quality Framework)をベースとした独自のフォーマットを活用して、テスト設計を行っています。
SHIFTのソフトウェアテスト・第三者検証とは？

シナリオテスト設計時の4つのポイント

考慮すべきポイントについても解説します。

1. テスト観点を事前に考える

ただシナリオを流すだけでは、確認すべきポイントを見逃してしまうことがあります。

見逃しを防ぐためには、事前にテスト観点を考えることでテストの狙いを明確にする必要があります。

また、テスト観点とシナリオの対応を事前に整理しておくことにより、必要なケースが漏れにくくなったり、シナリオの分岐条件となる因子や水準値の考慮漏れも防ぎやすくなったりします。

2. 要素分解することでインプット情報の複雑さを解きほぐす

多くの業務プロセスは複雑です。業務フロー図ですべてが表現しきれるわけではありません。
また、業務関連のドキュメントは様々な様式が存在していることが多く、テストのインプットも業務フロー図、運用マニュアルやチェックリストのようなドキュメントと多岐にわたります。くわえて、可視化されていない有識者知見までもがインプットとなることがあります。

そのため、シナリオテストがどのような要素で構成されているかを整理することが必要です。業務フローの分岐に着目し、分岐のない1本ずつのシナリオに分割していくといった作業を行うことで、複数の条件がからみあってわかりにくいシナリオでもテストのパターンを出しやすくなります。また、視認性も向上することから、有識者のレビューもしやすくなります。

3. 業務プロセスからテストケースまで体系立てて落とす

業務プロセスをシナリオやテストケースと体系立てて落とし込むことにより、同じ業務プロセスを対象にしたテストケースを複製しやすくなり、生産性高くテスト設計をすることができます。

また、業務プロセスがどのシナリオ、どのケースに反映されているのか、トレーサビリティも取りやすくなります。そのため、業務プロセスに変更があった場合にも影響範囲の特定やケースの修正・変更もしやすくなり、メンテナンス性が向上します。

4. 有識者レビューを行う

どんなに業務を理解しようとしても、実際に業務を行っている人でないとわからないことや気づけないことがあります。
テストケースが業務プロセスを正確に再現しているのか、必要な業務やテスト観点が網羅されているのかなど、有識者にレビューしてもらうことによってはじめて、適切なケースが作られているのかを確認することができます。そして、レビューと修正を繰り返し、ブラッシュアップしていくことが重要です。

まとめ

今回は、業務プロセスからどのように「シナリオテスト」のケースを作るのか、テスト設計時のステップとポイントについて解説をしました。シナリオテストは、システムの振る舞いが実際の業務の流れを実現できるかを確認する重要なテストです。現場のシナリオテストの品質を高めるために、今回紹介した内容がお役に立てば幸いです。

前のページへ

次のページへ

コラム一覧に戻る

シナリオテストとは？業務をどうやって分解していくの？

Introduction

業務を想定した「シナリオテスト」とは

業務をどのように実施可能なテストケースまで分解していくのか