シナリオテストのサンプル 項目書の書き方と業務別の記載例・粒度の決め方

「シナリオテストをやってくださいと言われたが、何をどう書けばいいのか分からない」「テストケースとの違いも曖昧なまま作り始めてしまった」。テスト工程に初めて関わるときの典型的な状況です。

シナリオテストは、利用者が一連の流れに沿ってシステムを問題なく使えることを確認するテストです。機能が単体で動くかではなく、業務が端から端まで通るかを検証します。

機能ごとのテストをすべて通しても、業務の流れとしては破綻しているということが起こります。個々の部品は正しいのに、つなげると動かない。この種の問題を検出するのがシナリオテストの役割です。

この記事では、そのまま使える項目書の様式と記載例を示したうえで、業務別のサンプル、作り方の手順、粒度の決め方、そして異常系の洗い出し方までを扱います。

確認したいポイント	結論	詳細
シナリオテストとは？	業務の流れを通して確認するテスト	機能単体ではなく、利用者の一連の操作が問題なく通るかを検証します。
テストケースとの違いは？	何をテストするかと、どう行うか	シナリオは検証する業務の流れ、ケースはその具体的な手順と期待結果です。
項目書に必要な列は？	ID・前提条件・操作手順・期待結果	この4つが基本です。実施日と結果を記入する欄もあわせて設けます。
何件くらい作る？	重要なシナリオを厳選する	全パターンの網羅は工数的に現実的ではありません。優先順位で絞ります。

この記事でわかること

• シナリオテストの位置づけと、単体テストや機能テストとの違い
• テストシナリオとテストケースの違い、そして両者の関係
• そのまま使える項目書の列構成と、1シナリオ分の記載例
• EC、申請承認、基幹業務という3パターンの業務別サンプル
• 粒度と件数の決め方、異常系シナリオの洗い出し方

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発や試験の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

シナリオテストとは

シナリオテストは、利用者が一連の流れに沿ってシステムを問題なく利用できることを確認するためのテストです。開発者の視点ではなく、利用者の視点での確認が中心になります。

たとえばECサイトであれば、商品を探し、カートに入れ、会員登録し、決済し、注文完了メールを受け取るまでを1つの流れとして実行します。途中のどこかで止まれば、業務としては成立していません。

どのテスト工程で実施するか

システムテストと受入テストで用いられる技法です。単体テストや結合テストより後の工程になります。

シナリオテストは、このうちシステムテストから受入テストの段階で使われる設計の考え方だと捉えると位置づけが分かります。前の工程で個々の部品が動くことを確認してから、流れの検証に進みます。

単体テストや機能テストとの違い

確認する単位が違います。これが最も本質的な違いです。

• 単体テスト：関数やモジュールが仕様どおり動くか。開発者が実施
• 機能テスト：1つの機能が仕様どおり動くか。画面単位で確認する
• シナリオテスト：複数の機能をまたぐ業務の流れが成立するか

機能テストをすべて通してもシナリオテストで落ちることがあります。登録画面も検索画面も個別には動くが、登録したデータが検索で出てこない。こうした問題は、流れを通さないと見つかりません。

観点も違います。機能テストは仕様どおりかを見ますが、シナリオテストは業務として使えるかを見ます。仕様を満たしていても、実務では手順が煩雑すぎて使えないという指摘が出ることもあります。

なぜ必要なのか

現代のシステムは、複数の機能が連携して動作します。個々の機能が動いていても、全体のフローが破綻している場合があります。

とくに問題になるのが、機能と機能の境界です。前の画面で作られたデータが次の画面で正しく引き継がれるか、複数のシステムをまたぐときに値が変換されるか。境界に問題が集中します。

発注側にとっては、検収の根拠になるテストでもあります。業務が通ることを確認できて初めて、システムを受け入れられます。

誰が作るのが適切か

業務を知っている人が関わらないと、実態に合わないシナリオになります。これがこのテストの特性です。

開発側だけで作ると、仕様書に書かれた流れをなぞることになります。しかし実際の業務には、仕様書に現れない手順や例外が含まれています。

現実的な進め方は、開発側が様式と土台を作り、業務部門が内容を確認・補足するという分担です。受入テストで使う場合は、業務部門が主体で作ることになります。

発注側にとっては、この作業が検収の準備そのものです。どのシナリオが通れば受け入れるのかを決める作業であり、開発側に任せきりにすべきものではありません。

テストシナリオとテストケースの違い

混同されやすい2つの言葉を整理します。ここが曖昧なまま作業を始めると、成果物の粒度が定まりません。

何をテストするか、どうテストするか

テストシナリオは「何をテストするか」、テストケースは「テストする方法」を記載します。これが基本的な区別です。

テストシナリオは、検証したい業務の流れそのものを指します。「新規会員が商品を購入する」という単位です。抽象度が高く、詳細な手順は含みません。

テストケースは、実行条件、入力データ、テスト手順、期待値、結果の仕様で構成されます。1つのシナリオを実行可能な形に落とし込んだものです。

呼び方の整理

実務では呼び方が揺れます。プロジェクト内で定義を揃えることが先です。

この記事では、完成する文書全体を「テスト項目書」、その中の個々の検証単位を「テストケース」と呼び分けます。業務フローを1件ずつのテストケースに落とし込み、それらを一覧化したものがテスト項目書という整理です。

「シナリオテスト」はテストの種類、「テストシナリオ」は検証する流れ、「テスト項目書」は文書。この3つを区別しておくと会話が噛み合います。

両者の関係

1つのシナリオから複数のテストケースが生まれるというのが一般的な関係です。

「新規会員が商品を購入する」というシナリオに対して、クレジットカード決済の場合、代金引換の場合、在庫切れの場合というように、条件を変えた複数のケースが展開されます。

まずシナリオを洗い出し、次にケースへ展開するという2段階で進めます。いきなりケースから書き始めると、業務の流れとしての網羅性が確認できません。

シナリオテスト項目書のサンプル

そのまま流用できる様式を示します。表計算ソフトで作成するのが一般的です。

基本の列構成

次の9列があれば実用に足ります。プロジェクトの規模に応じて削って構いません。

【列構成】

1. シナリオID　　（例：SC-001）

2. 業務名　　　　（検証する業務の名称）

3. 前提条件　　　（開始時点で満たしている状態）

4. 実施者　　　　（どの役割の人が実行するか）

5. 操作手順　　　（番号を振った手順）

6. 入力データ　　（使用する具体的な値）

7. 期待結果　　　（何が起これば正しいか）

8. 優先度　　　　（高・中・低）

9. 実施日／結果／不具合番号（実施時に記入）

7列目の期待結果が最も重要です。ここが書かれていないと、実施者が合否を判断できません。「エラーが出ないこと」ではなく、何が起こるのかを具体的に書きます。

記載例（1シナリオ分）

実際の記載例を示します。ECサイトでの新規会員による購入を題材にします。

シナリオID：SC-001

業務名　　：新規会員が商品を購入する（カード決済）

前提条件　：・対象商品の在庫が3個以上ある

　　　　　　・使用するメールアドレスは未登録

　　　　　　・検証用のテストカードが使用可能

実施者　　：一般利用者（未ログイン状態から開始）

操作手順　：1. トップページを開く

　　　　　　2. 検索欄に「テスト商品A」を入力し検索する

　　　　　　3. 検索結果から該当商品をクリックする

　　　　　　4. 数量を2に変更し、カートに入れる

　　　　　　5. カート画面で金額を確認し、購入手続きへ進む

　　　　　　6. 会員情報を入力し登録する

　　　　　　7. 配送先と配送方法を選択する

　　　　　　8. カード情報を入力し、注文を確定する

入力データ：氏名／テスト太郎、メール／test01@example.com

　　　　　　カード／検証用番号（マニュアル記載のもの）

期待結果　：・注文完了画面に注文番号が表示される

　　　　　　・登録したアドレスに注文確認メールが届く

　　　　　　・管理画面の受注一覧に同じ注文番号で登録される

　　　　　　・対象商品の在庫が3個から1個に減る

優先度　　：高

期待結果を4点に分けているのが要点です。画面の表示だけでなく、メールの送信、裏側のデータ、在庫の増減まで含めます。画面だけ見て合格とすると、連携の不備を見逃します。

各列に何を書くか

書き方で迷いやすい列について補足します。

前提条件には、開始時点で満たしているべき状態を書きます。マスタの登録状況、在庫数、権限、他のシナリオとの実施順序。ここが曖昧だと、実施者ごとに結果が変わります。

入力データには、具体的な値を書きます。「適当な氏名」ではなく「テスト太郎」と書きます。実施者が値を考える余地を残さないことで、再現性が確保されます。

優先度は、実施の順序と、期間が足りない場合に削る判断に使います。業務の中核を通るシナリオは高、例外的なものは低と分けます。

実施と記録の運用

項目書は実施の記録も兼ねます。9列目の記入欄をどう使うかを決めておきます。

記入するのは、実施日、実施者、結果（合格・不合格・未実施・対象外）、不具合番号です。不合格の場合は必ず不具合番号を記載し、後から突き合わせられる状態にします。

進捗の管理にも使えます。全件に対する実施済みの割合、合格率、不合格の件数。この3つを日次で集計すれば、テストの進み具合と品質の傾向が見えます。

修正後の再実施も記録します。1回目は不合格、修正後に合格という履歴が残ることで、どの不具合がどのシナリオで見つかったかを追えます。

テスト範囲の見極めからご相談いただけます 書き方は分かっても、自社の業務で何をどこまで確認すべきかの判断は別の問題です。業務の整理からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

業務別のサンプル

業務の性質によって、シナリオの組み方が変わります。代表的な3パターンを示します。

ECサイト｜購入フロー

利用者の行動が分岐しやすいという特徴があります。会員か非会員か、決済手段は何か、在庫があるか。シナリオを条件別に分けます。

SC-001　新規会員が購入する（カード決済）

SC-002　既存会員が購入する（ポイント併用）

SC-003　非会員が購入する（ゲスト購入）

SC-004　在庫切れの商品をカートに入れようとする

SC-005　購入手続きの途中で離脱し、再開する

SC-006　注文後にキャンセルする

SC-007　複数商品をまとめて購入する（送料の判定）

SC-004以降が異常系と例外です。正常系だけを並べて終わりにすると、実際に問い合わせが発生する部分を検証できません。

社内システム｜経費申請の承認フロー

複数の役割が登場するのが特徴です。申請者、承認者、経理担当。それぞれの操作をシナリオに含めます。

SC-101　申請者が経費を申請し、上長が承認する

SC-102　金額が10万円以上で、部門長の承認が追加される

SC-103　上長が差し戻し、申請者が修正して再申請する

SC-104　上長不在時に、代理承認者が承認する

SC-105　締め日後に申請しようとする（受付不可の確認）

SC-106　経理が承認済み申請を一括で出力する

役割をまたぐシナリオでは、実施者を切り替える手順を明記します。「ログアウトして承認者でログインする」という操作も手順に含めます。

SC-103の差し戻しと再申請は、実務で最も頻発する流れです。正常系より優先度を高く置く判断もあります。

基幹業務｜受注から出荷まで

複数のシステムをまたぐのが特徴です。受注、在庫、出荷、会計が連携します。

SC-201　受注登録から出荷指示、売上計上までが通る

SC-202　在庫不足時に取り寄せの手配が発生する

SC-203　受注を修正した場合、後続のデータも修正される

SC-204　受注をキャンセルし、在庫が戻る

SC-205　夜間バッチ実行後に、会計システムへ連携される

SC-206　月次締め処理を実行し、翌月の受付が開始される

SC-205のようにバッチをまたぐシナリオでは、実施に日数がかかります。前提条件に「前日の受注が登録済み」といった記載が必要になり、実施の順序も管理が必要です。

システム間の連携部分は、両方のシステムで結果を確認します。送信側だけを見て合格とすると、受信側での不整合を見逃します。要件の書き方については要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

作り方の5ステップ

業務フローの可視化から始めます。テストケースを直接書き始めると、網羅性が確認できません。

ステップ1｜業務フローを可視化する

誰が何をどの順序で行うかを図にします。既存の業務フロー図があれば流用します。

図がない場合は、現場の担当者に普段の作業手順を書き出してもらいます。開発側が作った図では、実務の細部が抜けます。

この段階で、登場する役割とシステムをすべて洗い出します。後でシナリオの実施者を決める際に使います。

ステップ2｜シナリオを洗い出す

業務フローの中から、検証すべき流れを単位として切り出します。この時点では詳細な手順は書きません。

洗い出しの軸は3つです。利用者の種類、条件による分岐、例外的な流れ。それぞれについてシナリオを立てます。

一覧の形でまず並べます。前章の業務別サンプルのように、IDと名称だけの一覧を作る段階です。ここで抜けがないかを確認します。

ステップ3｜テスト観点を検討する

各シナリオについて、何を確認したいのかを明確にします。画面の表示か、データの登録か、連携か、性能か。

観点が決まると、期待結果に何を書くべきかが定まります。観点を決めずに手順だけ書くと、何を見ればよいか分からない項目書になります。

あわせて優先度を付けます。業務の中核を通るシナリオ、影響範囲が大きいシナリオを高く設定します。

ステップ4｜テストケースへ展開する

シナリオを、実行可能な手順と期待結果まで具体化します。前章で示した様式を埋めていく作業です。

1つのシナリオから複数のケースに分かれる場合があります。決済手段が3種類あるなら、3件のケースになります。条件の組み合わせが多い場合は、優先度で絞ります。

入力データは具体的な値まで決めます。テストデータの準備も、この段階で洗い出します。

ステップ5｜有識者にレビューしてもらう

業務を知っている人に確認してもらう工程です。省略すると、実態と合わない項目書が残ります。

確認してもらうのは2点です。業務の流れとして正しいか、抜けているシナリオはないか。現場の担当者からは「この例外が頻発する」という指摘が出てきます。

指摘を反映して修正します。1回目の項目書は必ず抜けがあります。2回から3回のレビューを経て、使える状態になります。

粒度と件数の決め方

実務で最も判断に迷う部分です。目安を整理します。

1シナリオの範囲

業務として意味のある単位で区切ります。「受注を登録する」だけでは短すぎ、「受注から請求まで」では長すぎることがあります。

目安は、1人の担当者が一続きの作業として行う範囲、あるいは1つの成果物が完成するまでです。操作手順が5から15程度に収まる大きさが扱いやすくなります。

長すぎると、途中で失敗したときに残りを実施できません。分割できる箇所で区切ると、再実施の負担が軽くなります。

件数の目安

すべてのシナリオを網羅することは、工数的に現実的ではありません。あらゆる操作を想定したシナリオを用意して網羅的に調べることは可能ですが、非常に多くの工数がかかります。

そのため、例外的な対応が必要になる事象も含めて、重要なシナリオを厳選するという判断になります。

規模感の参考として、IPA（情報処理推進機構）のソフトウェア開発分析データ集では、総合テストのテストケース数がソースコード1,000行あたり中央値16.0件という実績が示されています。シナリオテストはこの一部であり、全体の中での配分を考える材料になります。

テストデータの準備

見落とされやすい準備作業です。シナリオを作った後、それを実行できるデータが必要になります。

必要なのは、マスタデータ（顧客、商品、部門、ユーザー）と、シナリオの前提となるトランザクションデータです。「在庫が3個ある商品」を用意しないと、SC-001は実行できません。

項目書を作りながら、必要なデータの一覧も同時に作るのが効率的です。前提条件の列を横断して見れば、必要なデータが洗い出せます。

本番相当のデータを使う場合は、個人情報の取り扱いに注意します。氏名や連絡先はマスキングし、件数と分布だけを再現するのが一般的な進め方です。

網羅しないという判断

絞る基準を明文化しておくことが重要です。「なぜこのシナリオを作らなかったのか」を説明できる状態にします。

基準は、業務の発生頻度、影響の大きさ、代替手段の有無です。月に1回しか起きず、起きても手作業で回避できる業務は優先度を下げられます。

対象外としたシナリオは一覧に残し、対象外である理由を記載します。検収の際に、確認範囲の合意の根拠になります。

異常系シナリオの洗い出し方

正常系だけで終わらせないことが、シナリオテストの価値を決めます。実務で問い合わせになるのは例外の部分です。

中断とキャンセル

途中でやめる、後から取り消すという流れです。実務では日常的に発生します。

入力途中でブラウザを閉じる、確認画面から戻って修正する、完了後にキャンセルする。それぞれでデータが不整合な状態にならないかを確認します。

キャンセル時の巻き戻しは特に注意が必要です。在庫が戻るか、ポイントが返るか、連携先に取り消しが伝わるか。個別に期待結果を書きます。

権限と代理

権限のない人が操作した場合の挙動を確認します。エラーメッセージが適切か、そもそも画面に到達できないか。

承認を伴う業務では、代理承認のシナリオを必ず含めます。担当者の不在は必ず起こるため、この流れが動かないと運用が止まります。

退職者や異動者のアカウントも観点になります。申請中に承認者が異動した場合にどうなるかは、仕様に書かれていないことが多い部分です。

データの境界

極端な値を入れたときの挙動を確認します。テスト用の無難なデータだけでは、実データ特有の問題を見逃します。

桁数の上限に近い金額、極端に長い会社名、旧字体や外字を含む氏名、0件や1件の一覧、100件を超える明細。実際の業務で扱う条件に近い値を混ぜます。

日付の境界も重要です。月末、年度末、うるう年、締め日の前後。これらは実務で確実に発生し、かつ不具合が出やすい箇所です。

タイミングと同時操作

複数の人が同時に操作した場合の挙動です。1人での操作では再現しないため、見落とされやすい部分です。

2人が同じデータを同時に編集する、在庫が1個のときに2人が同時に購入する、バッチ実行中に画面から更新する。後から保存した内容だけが残るという事象が起きないかを確認します。

検証には2つのブラウザを使います。手作業でも実施できるため、必ず1件は含めておきます。

よくある失敗

項目書を作っても機能しないというケースの原因を整理します。

機能一覧をなぞってしまう

最も多い失敗です。設計書の機能一覧を上から順にテストケースにすると、シナリオテストになりません。

それは機能テストの延長であり、機能と機能の境界は検証されません。業務の流れを軸にするという原則から外れています。

対策は、業務フローから作り始めることです。機能一覧を見ずに、現場の作業手順から出発します。

期待結果が書かれていない

手順だけが並び、何が起これば正しいのかが書かれていない項目書です。実施者が判断できません。

「エラーが出ないこと」という記載も不十分です。何も表示されないのが正常なのか、特定のメッセージが出るのが正常なのかが分かりません。

画面の表示、データの登録、通知の送信を分けて書くのが確実です。1つの手順に対して複数の期待結果があって構いません。

前提条件が曖昧

実施者によって結果が変わる原因です。在庫数、マスタの状態、実施の順序が書かれていないと、再現性がありません。

「他のシナリオを実施した後だと動かない」という状況も起こります。データの状態が変わっているためです。

対策は、前提条件を具体的に書き、実施順序を管理することです。あるいは、各シナリオの実施前にデータを初期状態へ戻す手順を用意します。

正常系だけで終わる

期間が足りず、異常系を削ってしまうというパターンです。しかし実務で問題になるのは、たいてい例外の部分です。

正常系を100件用意するより、正常系50件と異常系30件のほうが検出できる不具合は多くなります。配分を意識して計画します。

優先度を先に付けておくことが対策になります。期間が足りなくなったとき、削るのは優先度の低いものであり、異常系を一律に削るという判断にはなりません。委託時の役割分担についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも整理しています。

まとめ

シナリオテストは、利用者が一連の流れに沿ってシステムを使えることを確認するテストです。システムテストから受入テストの段階で用いられます。

項目書の列構成は、シナリオID、業務名、前提条件、実施者、操作手順、入力データ、期待結果、優先度、結果記入欄の9つが基本です。

期待結果を具体的に、複数に分けて書くことが最大の要点です。画面の表示だけでなく、データの登録、メールの送信、在庫の増減まで含めます。

作り方は5ステップです。業務フローを可視化し、シナリオを洗い出し、観点を検討し、ケースへ展開し、有識者にレビューしてもらう。機能一覧からではなく業務フローから始めます。

まずは自社の業務を1つ選び、シナリオの一覧だけを作ってみてください。IDと名称を並べた段階で、異常系がいくつ必要かが見えてきます。

開発とテストの進め方から、無料で相談できます 受け取ったテスト項目書の妥当性を判断したい、社内に開発の知見がなく不安があるといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎