シナリオテストの基本プロセスとそのポイント
はじめに
QAチームとして、第三者検証の一環でシナリオテストを実施する機会が多いです。
シナリオテストは総合テストで選択されることが多く、業務フローに基づいた操作を通じてシステムを検証することができ、
業務に近い状況でインパクトの大きい障害を効果的に発見することが可能です。
一方、業務フロー関連ドキュメントのないプロジェクトもあり、シナリオテストの導入が難しかったり、
シナリオテストを設計する上でのよくある課題もあります。
今回は、シナリオテストのプロセスについて、具体的な手順とそのポイントを整理して紹介します。
シナリオテストとは？
定義
実際の業務フローや利用シーンに基づいたテスト手法
ユーザーの一連の操作を想定したテスト
複数の機能を組み合わせた統合的なテスト
特徴
ユーザー視点での検証が可能
機能間の連携を確認できる
実際の利用状況に即した確認が可能
要件ベースのテスト
インパクトの強い障害が検出できる
シナリオテストのメリットとデメリット
シナリオテストを効率的に行うためには様々なリスクと対策を考慮する必要があります。
メリット
・実際の操作感を反映しやすい
ユーザーがシステムをどのように利用するかを想定したテストのため、実際の操作感に近いテストが可能
・仕様上の不備や不整合を発見しやすい
一連の操作フローをテストすることで、個々の機能だけでなく、機能間の連携や整合性の問題を発見できる
・複数の画面・システムを一連でチェックできる
複数の画面やシステムを跨ぐ一連の操作をテストできるため、システム全体の動作確認に役立つ
・効率的なテストが可能
ユーザーの利用シーンを想定したテストケースを作成することで、テストの効率化を図ることができる
・ユーザーの満足度向上
システムが正しく動作することを保証し、ユーザーの満足度向上に繋がる
デメリット
・網羅的に行うには膨大な工数が必要
リスク：テスト範囲が広すぎて現実的な時間内に完了しない、リリースが遅れる可能性
対策：テストの優先順位を決定し、リスクが高い部分を重点的にテストする
対策：探索的テストを導入し、シナリオ外の操作や予期しない状況を検証する
シナリオテストのプロセス
1. ユーザー業務の調査
シナリオテストの第一歩は、ユーザーがシステムをどのように使うかを理解することです。
つまり、ユーザーの代表的な使用方法をリストアップして、その使用シナリオを把握する必要があります。
しかし、プロジェクトによっては業務フロー関連ドキュメントが存在しないことがあります。
その場合の対応策も含めて説明します。
業務フロー関連ドキュメントが存在する場合
- 業務フロー図やユースケースドキュメントを確認する
- 業務フローを基に使用方法をリストアップする
業務フロー関連ドキュメントが存在しない場合
- ユーザーストーリーやPBIの内容を確認し、ユーザーのニーズや課題を明確にする
- 画面機能設計書を確認し、画面の遷移や機能の関連性を明確にする
2. シナリオの作成
手順1の調査結果からシナリオ名を定義します。
ここでは、正確な設計のためにシステムやアプリの要件（全体像、ユーザーのニーズ、仕様）を深く理解していることが求められます。
シナリオは以下の分類ごとに作成します。
正常系：一般的で標準的な操作フローを含むシナリオ
準正常系 ：想定内の異常処理や特別な条件に対して正常に動作するかを確認するシナリオ
異常系：例外的な操作や異常な状況を取り扱うシナリオ
シナリオを作成するポイントは以下になります。
ポイント
・どこからどこまでをシナリオの範囲とするか？
対象シナリオの操作範囲でどこからどこまでをカバーするか、悩む場合があると思います。
基本的にはユーザーの目的に基づき、テストの有効性と効率性を考慮して範囲を決めます。
外部システムや他モジュールとの連携部分もシナリオに含めるかどうか検討しつつ、
高リスク領域や過去に問題が発生しやすかった箇所を重点的にテスト範囲に含めます。
テストの粒度としては、シナリオが具体的かつ再現性の高いものであることを確認します。
ただ、あまり細かすぎると管理が煩雑になるため、バランスをとります。
・機能ごとにシナリオを分けない
CRUD「作成（Create）」、「読み取り（Read）」、「更新（Update）」、「削除（Delete）」ごとにシナリオ分けず、
一連の流れとしてシナリオを設計したほうが効果的です。
業務フローでは、複数のCRUD操作が連続して行われることが一般的であり、CRUDごとに分けると、
こうした一連の流れを十分にカバーできない可能性があります。
・ユーザータイプやアクターの種類によるシナリオ分け
ユーザータイプや操作を行うアクターごとに挙動が異なる場合は、
シナリオを分けて作成するか、前提条件を分けるかを選択する必要があります。
例えば、シナリオをそれぞれのアクターに対して個別に作成すると、見分けやすくなる一方、シナリオの数が増えます。
一方、シナリオの前提条件を設定して、同じシナリオ内でアクターごとの条件を変えると、シナリオが増えず、
一部の条件だけ変更することで、複数のアクターに対応できるシナリオが作成できます。
3. シナリオテストケースの作成
シナリオテストケースとして、以下の内容を記載します。
前提条件：各シナリオに必要な前提条件や初期設定を明確にする
詳細な手順：各シナリオに対して、実現するための詳細な手順を記載する
期待結果：各手順に対する期待する結果を明記
おわりに
以上、シナリオテストの基本プロセスについてご紹介しました。
これからもさらなる品質の向上のため、知見を深め、新しい挑戦を続けていきます。
