2024
9/13
ユーザー受入テストのうちの1つ
シナリオテストは、ユーザー受入テスト（UAT）の4種類のうちの1つです。
いずれも、ベンダーとは異なる観点でのテストであり、ベンダーがテストしたからOKとはなりません。ユーザー側で責任をもって行う必要があります。
（要求機能テスト）
・各機能単位で確認するテスト
・現場視点でバリエーションを確認する
例1：請求書レイアウトパターン網羅
例2：各画面項目の過不足
（システム間連携テスト）
・新システムと外部システムの連携部分を確認する
・ベンダーは外部システムは直接操作できないので、ユーザーにて外部システムを直接操作し、確認する
（シナリオテスト）
・業務の流れを上から下まで、取引を「通し」で確認する
・実際の取引を再現し、業務が回るかを確認する
（現新比較テスト）
・現行と新でシステム出力結果が一致するかを確認する
・主に全件データで集計結果が一致するかを確認する
・移行データ（マスタ・トランザクション）が正しいか確認する
（※ 画像をクリックすると、大きな画像が表示されます）
シナリオテストの位置づけ
シナリオテストは、実際の業務の流れを「通し」で確認するテストです。
ベンダーは、システム機能の観点でテストはできますが、「現場業務が回るか？」という観点ではテストができません。つまり、現場ユーザーでしかできないテストといえます。
また「主要な業務フロー」で一通りの処理が回ることを確認できると、一気に安心感が高まります。
さらに、シナリオテストを通じて、複数の機能を跨ることで、ユーザーは全体像を把握し、新システムの理解が深まるメリットもあります。
シナリオテスト項目書のイメージ
まずは、シナリオテストを具体的にイメージしてもらうため、テスト項目書のサンプルをご覧ください。
（※ 画像をクリックすると、大きな画像が表示されます）
左側に主要な機能（サブシステム）があり、上流から下流までの大きな流れと確認項目を記載しています。
ポイントは、確認項目を記載しすぎないことです。
画面の項目レベルで、全て確認していては大変です。そのレベルのテストは、むしろ要求機能テストで実施すべきです。
シナリオテストでは、主要なアウトプットに絞って確認していけばよいのです。例えば、請求書の内容が正しいこと、最後の仕訳データが正しいこと。
最後の出力結果が正しければ、途中の処理も正しかったとみなすことができます。
このような1つの流れが1つのシナリオであり、実際のシナリオテストとなります。
シナリオマトリックスのイメージ
しかしながら、シナリオは1つではありません。業務パターンの数だけシナリオは存在します。
では、シナリオは何本用意すればよいのでしょうか？
どのように漏れないように、網羅して整理していけばよいのでしょうか？
それが、シナリオを整理するための「マトリックス」です。
（※ 画像をクリックすると、大きな画像が表示されます）
このマトリックスは、業種によって作り方、必要となる項目は大きく変わります。
また、システムによっては「発注側フロー」と「受注側フロー」のように、複数のマトリックスが必要となるケースもあります。
シナリオテストの組み立て方
シナリオテストを組み立てていく上では、次のようなプロセスとなります。
①業務フローから大まかな流れやシナリオを決める
②処理パターンを網羅する（ノーマル／イレギュラー）
③テスト項目書に落とし込む
（※ 画像をクリックすると、大きな画像が表示されます）
マトリックスの考え方
シナリオマトリックスの作り方に正解はありません。
業種業界によって異なり、会社によって異なり、さらには作る人によっても異なります。
マトリックスは、シナリオを網羅するための手段にすぎないからです。
マトリックスを考える切り口としては、以下のようなものが挙げられます。
・主要取引先のパターンから考える
・主要商品のパターンから考える
・伝票のパターンから考える
・取引や契約形態のパターンから考える
ここで、いつも現場ユーザーの皆さんは悩みます。
そこで私は質問します。
「例えば、絶対にテストしておきたい取引先はどこですか？」
すると、たくさんの取引先を挙げてくれます。そこで
「なぜその取引先でテストしたいのですか？理由はありますか？」
と聞くと
「この取引先は返品が多いから」
「この取引先は一部仕入れが発生するから」
とスラスラ答えてくれます。
それこそが、シナリオテストで確認すべきパターンです。まずはそれらを列挙して、グルーピングして、表にまとめればいいのです。
（※ 画像をクリックすると、大きな画像が表示されます）
その上で、マトリックス完成後に、実際にテストするシナリオを決めていきます。
なぜなら、全シナリオを実施するには数が多すぎて、現実的ではないからです。
そこで、要求機能テストとの「兼ね合い」を考えていきます。
例えば、「請求書パターン」「返品パターン」「値引きパターン」「経費パターン」などの細かいバリエーションのテストは『要求機能テスト』で行う。それらのパターンから代表的なものだけを選抜して『シナリオテスト』で行う。
このように、要求機能テストとシナリオテストの棲み分けを合理的に決めていくのです。
前提として、要求機能テストで各パターンを網羅し、確認している必要があります。
テスト項目書の考え方
理想は、上で示したようにきちんとシナリオ毎に「テスト項目書」を作ること。
ただし、デメリットもあります。
シナリオ毎にテスト項目書をつくるのは、ユーザーに非常に大きな負担がかかります。20本のシナリオをテストするなら、20本のテスト項目書を作らないといけません。
もちろん、きちんと作ってやるのが理想的ではありますが、完璧を求めるとユーザーが途中で息切れしてしまいます。挫折してしまう可能性もあります。
情シスメンバーはテスト項目書の作成に慣れているので、そこまで負担はないかもしれません。しかし、ユーザーは不慣れなので、大きな負担を感じているかもしれません。このような配慮は必要です。
このとき、情シスが代筆して、マトリックスからテスト項目書を作り起こしていくのは、対策の1つです。
ただし、その場合は情シスの負担が一気に増えてしまいます。業務知識不足で、作れない部分もでてきます。また、ユーザー自身が手を動かしたり、考えたりする機会が少なくなるので、当事者意識が薄くなってしまいます。
そこで、もう1つの対策があります。
マトリックス自体をテスト項目書にしてしまう方法です。
マトリックスの右側にテスト実施日、テスト実施者、テスト結果などを付け足して「テスト項目書化」してしまうのです。
これは、シナリオテストの確認はざっくりでOK、最後の出力結果さえ正しければOK、細かいところは要求機能テストで見るから、という割り切った考え方に基づきます。
シナリオテストは合理的に、現場ユーザー中心で進めていきましょう！
（↓関連記事↓）
受入テスト（UAT）計画書の作り方（サンプル画像付き）
要求機能テスト項目書の作り方（サンプル画像付き）
リリース判定／本稼働判定の作り方（サンプル画像付き）
＊＊＊＊＊
※ 弊社で公開しているサンプルについては、基本的に画像のみの提供とさせていただいております。ファイルデータのダウンロードを可能とすると、内容の吟味をせずにそのまま流用し、トラブルに発展する可能性があるためです。画像データから文字起こしを行う過程で、それぞれのプロジェクトの状況に合わせてアレンジしていただければ幸いです。
