シナリオテストとは、ユーザーが実際に行う業務操作の流れに沿ってシステムの動作を通しで検証するテスト手法で、システムテストやUAT（ユーザー受入テスト）の工程で実施されます。
シナリオテストの項目書は、「シナリオID」「前提条件」「操作手順」「期待結果」等の列を持つテンプレートに、ユーザーの業務操作フローを1シナリオずつ記述して作成します。
本記事では具体的なサンプルと、業務フローからテストケースへ落とし込む手順を解説します。
網羅性の高いシナリオを設計し、抜け漏れなくテストをやり切るには、相応の知見と手間がかかります。自社のリソースだけでは難しいときは、テストの専門会社に任せる手もあります。
バルテス株式会社の品質向上サービスは、テストの計画・設計・実行を第三者の立場で支援するサービスです。シナリオ設計からテスト実行まで任せられる選択肢として、ぜひ検討してみてください。
シナリオテストの定義と他テスト手法との違い
シナリオテストは、ユーザーが実際に行う業務操作の流れに沿って、システムが正しく動作するかを通しで検証するテスト手法です。単体の機能確認ではなく、業務の流れ全体を検証する点に特徴があります。
開発者がコードの正しさを確かめるのに対し、シナリオテストは「実際の業務をシステム上で問題なく進められるか」をユーザーの視点で見ます。実施するのは主にシステムテストやUATの工程、つまりプロジェクトの後半です。
単体・結合・システムテストとの違い
シナリオテストを他のテストと比べるときは、「テスト工程（レベル）」と「テスト技法」という2つの区分を分けて考えると整理しやすくなります。
単体テスト・結合テスト・システムテストは、検証する範囲を段階的に広げていくテスト工程です。
一方、シナリオテストやE2Eテストは、その工程の中で用いる技法にあたります。シナリオテストはそれ自体が独立した工程ではなく、主にシステムテストやUAT（ユーザー受入テスト）の工程で実施される技法だという点を押さえておきましょう。
| テスト | 区分 | 主な対象 | 視点 | 位置づけ・実施タイミング |
| 単体テスト | テスト工程（レベル） | 個々の関数・モジュール | 開発者視点 | コーディング直後 |
| 結合テスト | テスト工程（レベル） | モジュール間の連携 | 開発者視点 | モジュール統合時 |
| システムテスト | テスト工程（レベル） | システム全体 | 開発者・ユーザー視点 | 結合テスト後 |
| シナリオテスト | テスト技法 | 業務フロー全体 | ユーザー視点 | システムテスト・UATの工程で実施 |
| E2Eテスト | テスト技法 | システム全体の通信経路 | 技術視点 | システムテスト等で実施 |
単体テストや結合テストが「部品やつなぎ目が仕様どおりか」を確かめるのに対して、シナリオテストが見るのは「ユーザーが実際の業務でたどる一連の操作が、最後まで滞りなく進むか」です。
同じ画面を動かしていても、確かめている対象が異なります。
また、E2Eテストに関しては、システム全体を通して見る点は似ていますが、E2Eが重視するのは、フロントエンド・API・データベース間の通信が技術的に正しくつながるかどうかです。
シナリオテストが見るのは、「顧客が注文を完了できるか」という業務上の結果になるので、同じ画面を触っていても、こちらも確かめている対象が異なります。
シナリオテスト項目書の作り方6ステップ
シナリオテストの項目書を作る手順は大きく6つのステップに分かれます。
なお本記事では、完成する文書全体を「テスト項目書」、その中に記載する個々の検証単位を「テストケース」と呼び分けます。業務フローを1件ずつのテストケースに落とし込み、それらを一覧化したものがテスト項目書です。
まずは、全体の流れと各ステップでやるべきことを見ていきましょう。
- 業務フローの可視化
- シナリオの洗い出しと整理
- テスト観点の検討と紐づけ
- テストデータの選定
- テストケースへの展開
- レビューと優先度付け
ステップ1 業務フローの可視化
シナリオテストの起点は、テスト対象の業務フローを目に見える形にすることです。すでに業務フロー図があればそれを使い、なければ業務担当者へのヒアリングやマニュアルから起こします。
材料になるのは、業務フロー図・画面遷移図・業務マニュアル・担当者へのヒアリングメモなどです。この段階では細かく描き込みすぎず、「どんな業務があり、主要な処理がどう流れるか」の全体像をつかめれば十分です。
ヒアリングをするときは、業務の始まりから終わりまでのきっかけ、判断の分かれ目、例外処理が起きる条件を、具体的に聞き出しておきます。ここを押さえておくと、あとのシナリオ洗い出しがぐっと楽になります。
ステップ2 シナリオの洗い出しと整理
可視化した業務フローを「シナリオ」単位に分解します。
シナリオとは、業務の始まりから終わりまでの一連の操作の流れのことです。ECサイトなら「商品検索→カート追加→決済→注文完了」が、正常系の1シナリオにあたります。
シナリオは「正常系」「異常系」「例外系」に分け、業務パターンごとに一覧にすると漏れを防げます。正常系は想定どおりに進む流れ、異常系は入力エラーや権限不足で処理が止まる流れ、例外系はまれにしか起きない特殊な分岐です。
整理にはシナリオ一覧表（マトリックス）が有効です。縦軸に業務プロセス（商品検索、カート操作、決済など）、横軸にシナリオの種類（正常系・異常系・例外系）を置き、各マスに具体的なシナリオ名を書き込んでいくと、全体の見通しがよくなります。
ステップ3 テスト観点の検討と紐づけ
シナリオを並べただけでは、「何を確認するのか」がはっきりしません。そこで、各シナリオで確かめるべき観点を決めます。
テスト観点とは、そのシナリオで検証する品質特性や確認項目のことです。
たとえば、入力した値が正しく保存・表示されるか（データの正確性）、画面が想定どおり遷移し戻るボタンも効くか（画面遷移）、権限のない人が操作できないか（権限制御）、エラー時に適切なメッセージが出るか（エラーハンドリング）、応答時間が許容範囲に収まるか（パフォーマンス）といった観点があります。
シナリオとテスト観点をマトリックスで掛け合わせると、抜け漏れを構造的に防げます。
縦軸にシナリオ、横軸に観点を置き、交点にテストケースがあるかどうかを記入していけば、どのシナリオでどの観点が手薄かが一目でわかります。
ステップ4 テストデータの選定
シナリオ観点を洗い出した後に、網羅すべきテストデータのパターンを洗い出します。
テストのリソースとリスクとのトレードオフによって、どの程度網羅するのかをテスト設計します。例えば、新機能であればパターン数を増やし、逆に既存機能であれば優先度の高いシナリオに絞ってテストを行います。
テスト設計の際には、テストデータについてレビュー受け、使用するデータの内容の合意を得ておくことが重要です。
ステップ5 テストケースへの展開
マトリックスで紐づけた内容を、実際に手を動かせるテストケースの形に具体化します。1件のテストケースには「前提条件」「操作手順」「期待結果」「使うテストデータ」をそろえ、実施者が迷わず進められる粒度で書きます。
前提条件には、テスト開始時に満たしておく状態を書きます（「ログイン済み」「カートに商品1点」「管理者権限でログイン」など）。操作手順はユーザーの動きを順番に、期待結果は各操作のあとにシステムが示すべき状態や表示を書きます。
テストデータには、入力値やマスタの具体的な中身を添えます。
目安は、「実施者が手順を見ただけで迷わず手を動かせるか」です。具体的な書き方は、次の章のサンプルで示します。
ステップ6 レビューと優先度付け
テストケースができたら、必ずレビューを挟みます。業務知識の不足による抜け漏れと、技術的な見落とし。この両方を防ぐため、業務に詳しい人と開発者の双方に見てもらうのが理想です。
業務に詳しい人には業務フローの再現性やシナリオの網羅性を、開発者にはテストケースが実装上問題なく実行できるか・技術的に妥当かを見てもらいます。両方の視点が入って初めて、テスト設計の質が安定します。
工数が足りないときは、優先度をつけます。利用頻度の高い業務や、リスクの大きい処理（金銭のやり取り、個人情報の扱いなど）から先にテストケースを作り、実施順を決めます。
すべてのシナリオを同じ密度でテストする必要はなく、重要度に応じてメリハリをつけるのが実務的です。
レビューで修正が入るのは当たり前で、最初から完璧を目指す必要はありません。何度かレビューを重ねながら、テストケースを育てていけば十分です。
シナリオテスト項目書の書き方サンプル
ここからは、完成したシナリオテスト項目書の具体的な形を見ていきます。
まずテンプレートの標準的な構成を押さえ、続いてECサイトと業務システムの2つの例でサンプルを示します。これをたたき台に、自社の業務に合わせて作り替えていくのがおすすめです。
項目書テンプレートの構成要素
シナリオテスト項目書のテンプレートには、以下の列を設けるのが標準的な構成です。
| 列名 | 説明 |
| シナリオID | テストケースを一意に識別する管理番号（例：TS-001）。テスト結果やバグ報告と紐づけられるようにする |
| シナリオ名 | シナリオの内容を端的に表す名称（例：正常系_商品購入フロー） |
| 前提条件 | テスト実施前に満たすべき状態（例：ログイン済み、カート内に商品1点）、テストデータ |
| 操作手順 | ユーザーが行う具体的なアクションを順序立てて記述 |
| 期待結果 | 各操作後にシステムが示すべき状態や表示内容 |
| 優先度 | テスト実施の優先順位（高・中・低、またはP1〜P3など） |
| 実施結果 | テスト実施後に記入（OK / NG / 保留など） |
| 備考 | 不具合番号、補足説明など |
各列の記入ポイントを簡潔に解説します。
シナリオIDは「TS-001」のように一意の管理番号を付与し、テスト結果やバグ報告と紐づけられるようにします。
前提条件は「ログイン済み」「商品が在庫あり状態」など、テスト開始時点でシステムが満たすべき状態を明記します。
「操作手順」と「期待結果」が最も重要な列であり、粒度を揃えることがポイントです。
操作手順は「1. トップページにアクセス」「2. 検索窓にキーワードを入力」のように、実施者が迷わず実行できる単位で記述します。
期待結果は各操作に対応する形で「検索結果一覧が表示される」「カート内の商品数が1増加する」のように具体的に書きます。
記述例①：ECサイトの購入フロー
ECサイトの「商品検索→カート追加→決済→注文完了」という購入フローのシナリオテスト記述例を、正常系と異常系の2パターンで示します。
■ 正常系シナリオの記述例
| 列名 | 内容 |
| シナリオID | TS-001 |
| シナリオ名 | 正常系_商品購入フロー |
| 前提条件 | ログイン済み、購入対象商品が在庫あり状態 |
| 操作手順 | 1. トップページの検索窓に「ノートPC」と入力2. 検索ボタンをクリック3. 検索結果一覧から任意の商品をクリック4. 商品詳細ページで「カートに追加」ボタンをクリック5. カート画面で「レジに進む」ボタンをクリック6. 配送先住所を入力し「次へ」をクリック7. 支払方法を選択し「注文確定」ボタンをクリック |
| 期待結果 | 1. 検索結果一覧に商品が表示される2. 商品詳細ページが表示される3. カート内の商品数が1増加する4. カート画面に商品名・数量・金額が表示される5. 配送先入力画面が表示される6. 支払方法選択画面が表示される7. 注文完了画面が表示され、注文番号が発行される |
| 優先度 | 高 |
| 実施結果 | （テスト実施後に記入） |
| 備考 | テストデータ：商品ID=12345、ユーザーID=test001 |
■異常系シナリオの記述例（在庫切れ商品の購入試行）
| 列名 | 内容 |
| シナリオID | TS-002 |
| シナリオ名 | 異常系_在庫切れ商品の購入試行 |
| 前提条件 | ログイン済み、購入対象商品が在庫0の状態 |
| 操作手順 | 1. トップページの検索窓に在庫切れ商品名を入力2. 検索ボタンをクリック3. 検索結果一覧から在庫切れ商品をクリック4. 商品詳細ページで「カートに追加」ボタンをクリック |
| 期待結果 | 1. 検索結果一覧に商品が表示される2. 商品詳細ページが表示される3. 「在庫切れのため購入できません」のエラーメッセージが表示される4. カートに商品が追加されない |
| 優先度 | 高 |
| 実施結果 | （テスト実施後に記入） |
| 備考 | 在庫切れ商品ID=67890で実施 |
記述例②：業務システムの申請・承認フロー
業務システム（経費精算を例とする）の申請→承認→差戻しフローのシナリオテスト記述例を示します。複数アクターが関わるシナリオと差戻し時の挙動を含めます。
■正常系シナリオの記述例（申請→承認完了）
| 列名 | 内容 |
| シナリオID | TS-101 |
| シナリオ名 | 正常系_経費精算申請から承認完了まで |
| 前提条件 | 申請者・上長・経理担当者がそれぞれログイン可能な状態 |
| 操作手順 | 【申請者操作】1. 経費精算申請画面にアクセス2. 経費項目（交通費）、金額（1,500円）、日付を入力3. 領収書画像をアップロード4. 「申請」ボタンをクリック【上長操作】5. 承認待ち一覧画面にアクセス6. 該当申請を選択7. 内容を確認し「承認」ボタンをクリック【経理担当者操作】8. 承認待ち一覧画面にアクセス9. 該当申請を選択10. 内容を確認し「承認」ボタンをクリック |
| 期待結果 | 1. 申請画面が表示される2. 入力内容がプレビュー表示される3. 領収書画像がサムネイル表示される4. 「申請が完了しました」のメッセージが表示され、申請番号が発行される5. 上長の承認待ち一覧に該当申請が表示される6. 申請詳細画面が表示される7. 申請ステータスが「上長承認済み」に更新され、経理の承認待ち一覧に移動する8. 経理の承認待ち一覧に該当申請が表示される9. 申請詳細画面が表示される10. 申請ステータスが「承認完了」に更新され、申請者に通知メールが送信される |
| 優先度 | 高 |
| 実施結果 | （テスト実施後に記入） |
| 備考 | 申請者ID=user01、上長ID=manager01、経理ID=accounting01 |
■異常系シナリオの記述例（上長による差戻し）
| 列名 | 内容 |
| シナリオID | TS-102 |
| シナリオ名 | 異常系_上長による差戻しと修正再申請 |
| 前提条件 | 申請者が経費精算を申請済み、上長が承認待ち一覧で確認可能な状態 |
| 操作手順 | 【上長操作】1. 承認待ち一覧画面にアクセス2. 該当申請を選択3. 差戻し理由（「領収書が不鮮明」）を入力4. 「差戻し」ボタンをクリック【申請者操作】5. 差戻し通知メールを確認6. 申請一覧画面にアクセス7. 差戻された申請を選択8. 領収書画像を再アップロード9. 「再申請」ボタンをクリック |
| 期待結果 | 1. 承認待ち一覧に該当申請が表示される2. 申請詳細画面が表示される3. 差戻し理由の入力欄が表示される4. 申請ステータスが「差戻し」に更新され、申請者に差戻し通知メールが送信される5. 差戻し理由を含むメールが受信される6. 申請一覧に「差戻し」ステータスの申請が表示される7. 申請編集画面が表示され、差戻し理由が確認できる8. 画像がプレビュー表示される9. 申請ステータスが「申請中」に戻り、上長の承認待ち一覧に再度表示される |
| 優先度 | 中 |
| 実施結果 | （テスト実施後に記入） |
| 備考 | 差戻し時のステータス遷移を確認 |
複数アクターが関わる業務システムでは、各アクターの操作と画面遷移を明記し、承認・差戻し・却下のパターンを網羅します。ECサイト例との違いとして、承認ステータスの遷移（申請中→上長承認済み→承認完了、または申請中→差戻し→再申請）を明確に書く点が挙げられます。
質の高いシナリオを書くための4つのコツ
サンプルを参考にしてもシナリオの質にバラツキが出るのはよくある課題です。オーティファイ株式会社の2024年調査（従業員3,000名以上の大企業104社対象）では、51.9%がリリース後の不具合発見を課題に挙げています。テスト品質の向上は、リリース後の手戻りコストを削減する上で重要な取り組みです。
ここでは、シナリオテスト項目書の品質を左右する4つの実践ポイントを解説します。作り方ステップを理解した後の、品質向上の視点に焦点を当てます。
4-1 テスト粒度の判断基準を設ける
粒度の見極めは悩ましいところです。細かすぎれば工数が膨れ上がり、粗すぎればバグを見逃します。迷ったら「実施者が手を止めずに動けるか」を基準にしてください。
たとえば「購入処理を行う」だけでは、実施者は何をすればいいか分かりません。逆に「マウスを動かす」「クリックする」まで分けると、手順が増えすぎて管理しきれなくなります。
目安は「1ステップ＝1アクション」です。「ボタンをクリック」「値を入力」くらいの単位を指します。
「商品詳細ページで『カートに追加』ボタンをクリック」がちょうどよい粒度で、マウスを動かすといった細部は省き、意味のある操作のまとまりで書きます。
4-2 異常系・エラー系シナリオを漏らさない
正常系は書けても、異常系がつい手薄になりがちです。代表的なのは、入力値の境界値（上限・下限を超える値、空欄、特殊文字）、権限不足（ログインせずにアクセス、他人のデータを見ようとする）、通信タイムアウト（決済中に応答が途切れる）、同時操作の競合（複数人が同じデータを同時に編集する）あたりです。
正常系1本につき、異常系を2〜3本洗い出しておくと漏れを抑えられます。
「商品購入」の正常系1本なら、「在庫切れ時の購入」「決済エラー時のリトライ」「配送先未入力での購入」の3本を添える、といった具合に整理をしていきます。
4-3 ユーザーの行動パターンから発想する
開発者が思い描く操作と、ユーザーが実際にやる操作は、しばしば食い違います。
ユーザー目線でシナリオを思いつくには、ペルソナを立てる（年齢・ITの慣れ・業務の習熟度を想定する）、操作ログから頻出パターンを拾う、現場の担当者に「困った経験」を聞く、といったやり方が役立ちます。
たとえば、決済画面まで進んだあとに戻るボタンで商品詳細へ戻り、もう一度カートに進んだとき、カートが二重登録されないか。こうしたシナリオは、開発者の視点では抜けがちです。
そこで、「ブラウザの戻るボタン」「途中で離脱して後から再開」といった生々しい操作からシナリオを起こすと、現場で実際に起きるバグを拾いやすくなります。
4-4 有識者レビューで網羅性を検証する
シナリオの質は、書いた人の業務知識に大きく左右されます。だからこそ、詳しい人のレビューが欠かせません。
頼む相手としては、業務を実際に回している現場の担当者、障害対応や問い合わせをさばいてきた運用チーム、似たシステムのテスト設計を経験した人などが候補になります。
レビューはシナリオ一覧ができた早い段階で入れるのがコツです。テストケースまで作り込んでから直すより、一覧の段階で「このパターンが抜けている」「この観点も要る」と指摘してもらうほうが、直す手間がずっと小さくて済みます。
バルテス株式会社のシナリオテスト支援サービスは、テストの設計・実行を専門に手がける第三者検証のサービスです。1,000件規模の標準テスト観点や、ISO/IEC/IEEE 29119に準拠したテストメソッド「QUINTEE」をもとに、抜け漏れの少ないシナリオ設計を支援します。在籍エンジニアのJSTQB取得率は95%、導入実績は1,300社にのぼります。自社のシナリオ設計に不安がある方は、ぜひご相談ください。
シナリオテストの書き方まとめ
シナリオテスト項目書は、業務フローの可視化から始めて、シナリオの洗い出し→テスト観点の検討→テストケースへの展開→レビュー、の5ステップで作ります。
テンプレートには「シナリオID」「前提条件」「操作手順」「期待結果」といった列を用意し、ユーザーの目線で業務の流れをなぞるように書いていきます。
記事ではECサイトと業務システムの2つのサンプルを挙げましたが、大事なのは自社の業務に合わせて作り替えることです。
まずはテンプレートをコピーして、自社の業務フローを書き出すところから始めてみてください。粒度の見極め、異常系の網羅、ユーザー行動からの発想、有識者レビューの4つを意識すれば、シナリオの質はぐっと上がります。
最初から完璧なシナリオを作ろうとする必要はありません。まずは主要な正常系から着手し、レビューを重ねながら異常系を少しずつ足していきます。
そうやって育てるほうが、無理なく網羅性を高められます。
とはいえ、シナリオ設計は奥が深く、品質を本気で担保しようとすると、専門的な知見と工数の確保が課題になります。自社だけで抱え込まず、テストの専門会社を頼るのも有力な選択肢です。
バルテス株式会社の品質向上サービスは、テストの計画・設計・実行から品質コンサルティングまでを第三者の立場で引き受けます。年間7,000件のプロジェクトで培ったノウハウと1,000件規模の標準テスト観点で、シナリオの抜け漏れを抑えながらテスト全体の質を底上げできます。
この機会にぜひご相談ください。
