このテンプレートを使用してください
ユーザー受け入れテスト（UAT）は、新しいシステムが実際に利用者にとって機能するかを確認できる最後のチャンスです。多くの場合、「請求書処理をテストする」といった曖昧なスクリプトを、何を確認すべきか分からない忙しい業務担当者が実行し、証拠としてスクリーンショットをメールに貼り付ける形になっています。その結果、欠陥が見落とされ、テスト結果を信頼できず、承認が意見の問題になってしまいます。UATテストスクリプトのテンプレートは、すべてのテストに同じ明確な構造（何をテストするか、どうやって、どのデータで、何が起きるべきか、実際に何が起きたか）を与えることで、この課題を解決します。
この無料のUATテストスクリプトテンプレートでは、テストの詳細、前提条件、テストデータ、期待結果と実測結果を含む番号付き手順、合否ステータス、証拠、欠陥、承認までをカバーします。入力済みの例が含まれており、業務担当者が手順をそのまま実行できるように書き方のガイダンスも提供します。さらに、スクリーンショットを貼り付ける代わりにテストを録画して証拠を記録する方法も用意されています。下記の構造をコピーするか、Trupeerで開いてプロジェクトに合わせてカスタマイズしてください。
UATテストスクリプトテンプレートとは？
UATテストスクリプトテンプレートは、ユーザー受け入れテストで業務担当者が従うステップバイステップの指示を、そのまま使える形式で用意したものです。各スクリプトは、発注書の作成から請求書の計上までのように、1つの業務シナリオをエンドツーエンドでテストします。前提条件とテストデータ、実行する手順、各手順の期待結果、実測結果、合否ステータス、記録された証拠、提起された欠陥を一覧化することで、業務側が「システムを本番稼働に進めてよいか」を判断できます。
UATテストスクリプトは、より広いテスト方針の中に組み込まれます。全体の計画については、テスト計画テンプレートをご覧ください。
なぜUATテストスクリプトテンプレートを使うのですか？
業務担当者はプロのテスターではありません。明確で番号付きの手順があれば、自信を持ってテストできます。
一貫したスクリプトは一貫した結果を生みます。そのため、比較できて信頼できます。
期待結果があれば、「正しい状態」が何かを推測する必要がありません。
証拠は承認と監査を支えます。何をテストし、何が起きたのかを正確に示します。
欠陥は、それが起きた手順と証拠に紐づいていれば、修正しやすくなります。
スクリプトはトレーニング資料になります。新しいシステムでの実際の作業を説明するためです。
UATテストスクリプトテンプレートは誰が使いますか？
テストマネージャーおよびUATリードが、ユーザー受け入れテストを計画し調整します。
業務担当者およびプロセスオーナーがテストを実行し、承認します。
ビジネスアナリストが要件からスクリプトを作成します。
ERP、CRM、HCMの導入チームが設定済みのシステムをテストします。
QAチームが欠陥管理と再テストを行います。
監査担当者およびコンプライアンスチームが、テストの証拠を必要とします。
UATテストスクリプトテンプレートをプレビュー
テンプレートは、テストスクリプトのヘッダー（ID、タイトル、ビジネスシナリオ、要件参照、テスター、環境、日付）から始まります。その後に前提条件とテストデータが続きます。メインの表には、各ステップのアクション、期待結果、実測結果、合否ステータス、証拠リンクが記載されています。スクリプトは、全体結果、提起された欠陥、再テスト結果、承認で締めくくられます。すべてのセクションは編集可能なので、列を追加したり、ステータス値を変更したり、テスト管理ツールにスクリプトを紐づけたりできます。
Trupeerでこのテンプレートをカスタマイズする方法
ステップ1：テンプレートセクションを開く
メインナビゲーションからテンプレートセクションへ移動します。
ステップ2：テンプレートを選択して開く
作業したい任意のテンプレートをクリックして開きます。
ステップ3：テンプレート表示を展開する
必要に応じて、テンプレート表示を展開して全体のレイアウトと詳細を分かりやすく確認します。
ステップ4：テンプレートを編集する
編集（Edit）をクリックして、選択したテンプレートの変更を開始します。
エディター内で、次のことができます：
新しいセクションを追加する
書式ルールを定義または更新する
ロゴを追加し、その位置および関連設定を調整する
ステップ5：カスタマイズしたテンプレートを保存する
必要な変更をすべて行ったら、保存（Save）をクリックして更新済みのテンプレートを自分のものとして保存します。
ステップ6：テンプレートをプレビューして微調整する
カスタマイズしたテンプレートの見え方を確認したいときは、プレビューを開きます。
プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。
UATテストスクリプトテンプレートがあれば、次のことができます：
業務担当者に、トレーニングなしで従える明確な手順を提供できます。
各ステップの期待結果で「正しい状態」を定義できます。
証拠を一貫して記録できます。理想的にはテストの録画として残します。
欠陥を、発生した正確な手順に紐づけできます。
署名済みで証拠のある結果に基づいて本番稼働の判断をサポート
UATテストスクリプトテンプレートに必ず含まれるもの
セクション | カバーする内容 |
|---|---|
スクリプトヘッダー | ID、タイトル、ビジネスシナリオ、要件参照、優先度 |
テスト詳細 | テスター、環境、テストサイクル、日付 |
前提条件 | ユーザーアクセスやセットアップなど、テスト前に成り立っている必要があること |
テストデータ | サプライヤー、マテリアル、金額など、使用するデータ |
テスト手順 | テスターが実行する番号付きアクション |
期待結果 | 各ステップで起きるべきこと |
実測結果 | 実際に起きたこと |
ステータス | 手順ごとおよび全体の合格／不合格／ブロック／未実施 |
証拠 | テストの録画またはスクリーンショット |
欠陥 | 欠陥ID、説明、失敗がある場合の重大度 |
再テスト | 再テスト日、結果、証拠 |
承認 | テスターおよび業務オーナーの承認 |
無料のUATテストスクリプトテンプレート：コピーするための構造
下記の構造を自分のドキュメントまたはスプレッドシートにコピーするか、Trupeerで開いてカスタマイズしてください。
1. スクリプトヘッダー。 スクリプトID：[UAT-P2P-001]。タイトル：[発注書を作成し、サプライヤーの請求書を計上する]。ビジネスシナリオ：[3者間照合による標準的な物品購入]。要件参照：[REQ-IDまたはフィットギャップID]。優先度：[高・中・低]。
2. テスト詳細。 テスター：[氏名と役割]。環境：[UATシステム]。テストサイクル：[サイクル1、2または回帰]。日付：[日付]。
3. 前提条件。 [テスターはUATシステムでバイヤーおよびAPクラークのロールを持っている。サプライヤーとマテリアルが存在する。許容差が設定されている。]
4. テストデータ。 サプライヤー：[サプライヤーID]。マテリアル：[マテリアルID]。数量：[数量]。価格：[価格]。コストセンター：[コストセンター]。
5. テスト手順。
ステップ | アクション | 期待結果 | 実測結果 | ステータス | 証拠 |
|---|---|---|---|---|---|
1 | [アクション] | [期待結果] | [実測結果] | [合格／不合格／ブロック] | [録画のタイムスタンプまたはスクリーンショット] |
2 | [アクション] | [期待結果] | [実測結果] | [ステータス] | [証拠] |
3 | [アクション] | [期待結果] | [実測結果] | [ステータス] | [証拠] |
6. 全体結果。 [合格／不合格／ブロック]。短いコメント付き。
7. 欠陥。 欠陥ID：[ID]。ステップ：[ステップ番号]。説明：[何が起きたか]。重大度：[critical（重大）／high（高）／medium（中）／low（低）]。
8. 再テスト。 日付：[日付]。結果：[合格または不合格]。証拠：[リンク]。
9. 承認。 テスター：[氏名、日付]。業務オーナー：[氏名、日付]。
UATテストスクリプトの例：発注書から請求書まで
調達から支払い（procure to pay）のシナリオに対する、入力済みのUATテストスクリプト例です。詳細は説明用です。
UAT-P2P-001 · 発注書を作成し、サプライヤーの請求書を計上する · 優先度：高
前提条件。テスターはUATでバイヤーおよびAPクラークのロールを持っています。サプライヤーとマテリアルが存在します。価格の許容差が設定されています。
テストデータ。サプライヤー：テスト用サプライヤーA。マテリアル：オフィスチェア。数量：10。価格：契約どおり。
ステップ | アクション | 期待結果 | 実測結果 | ステータス |
|---|---|---|---|---|
1 | サプライヤーAからオフィスチェア10脚の発注書を作成する | POが作成され、PO番号が表示される | 番号付きでPOが作成された | 合格 |
2 | 承認のためにPOをリリースする | POが承認者にルーティングされ、承認される | 承認済み | 合格 |
3 | 10脚分の入庫（goods receipt）を計上する | 入庫がPOに紐づけて計上される | 計上済み | 合格 |
4 | 契約価格でサプライヤー請求書を計上する | 請求書がPOと入庫に一致し、ブロックなしで計上される | ブロックなしで計上済み | 合格 |
5 | 許容差を超える価格の2通目の請求書を計上する | 請求書が価格差異のため支払いブロック付きで計上される | ブロックなしで計上済み | 不合格 |
全体結果。不合格。 欠陥。 DEF-112、ステップ5：許容差を超える価格差異が支払いブロックをトリガーしなかった。重大度：高。
再テスト。許容差の設定が修正された後、ステップ5を再テストし合格しました。証拠として録画を添付しています。
業務担当者が従えるUATテスト手順の書き方
1ステップにつき1アクションを、指示として書きます。「サプライヤー入力」ではなく「サプライヤーIDを入力する」。
システムの実際の画面名・項目名を使う。
各ステップの期待結果を具体的に書く。「動作する」ではなく「支払いブロックR付きで請求書が計上される」のようにします。
テストデータをスクリプトに含めることで、テスターが勝手にデータを作らないようにします。
ハッピーパスだけでなく例外もテストする。例：差異、承認の欠落、却下など。
各スクリプトは1つの業務シナリオに絞る。通常は5〜20ステップです。
すべてのスクリプトを要件またはフィットギャップ行に紐づける。
テストフェーズ全体で何を記録するべきかについては、UATドキュメンテーションのチェックリストをご覧ください。
ERP導入向けのUATテストスクリプト例
ほとんどのERPのUATサイクルでは、主要なエンドツーエンドのプロセスがカバーされます。まずは以下を起点として、例外やローカル要件に合わせてスクリプトを追加してください。
プロセス | 例：UATテストスクリプト |
|---|---|
調達から支払い（Procure to pay） | POを作成・承認し、入庫を計上、許容差内外で請求書を計上、支払い提案を実行 |
受注から入金（Order to cash） | 販売オーダーを作成し、クレジットブロックを解除、出荷と請求、入金の適用、クレジットノートの発行 |
記録から報告（Record to report） | 手動仕訳を計上・承認、減価償却を実行、未払計上を計上、期末クローズとレポートを実行 |
採用から退職（Hire to retire） | 従業員を採用し、職務変更と支払いを行い、退職者処理を実行し、給与のテストサイクルを実行 |
マスターデータ | 銀行の検証付きでサプライヤーを作成し、与信限度付きで顧客を作成し、マテリアルを作成 |
レポーティング | 主要な業務・財務レポートを実行し、期待合計と比較 |
業務リスクに基づいてスクリプトの優先度を決めましょう。資金の移動に関わるプロセス、顧客に影響するプロセス、法的に必須のプロセスを最優先にし、その後に高頻度の毎日業務を続けます。
UATの入出基準（entry/exit criteria）
UAT開始前にこれらを合意しておくことで、本番稼働の判断が意見ではなく証拠に基づくようになります。
基準 | 例 |
|---|---|
入場基準（Entry criteria） | システムテスト完了、UAT環境が安定、テストデータがロード済み、ユーザーアクセスがセットアップ済み、スクリプトが承認済み、テスターへのブリーフィングが完了 |
退出基準（Exit criteria） | すべての高優先度スクリプトが実行済み、未解決の重大／高の欠陥がない、中優先度の欠陥について合意済みの回避策が文書化されている、業務オーナーが承認済み |
UAT中は毎日進捗を追跡します。スクリプトが実行され、合格／不合格／ブロックになったか、また重大度別の欠陥は何かを確認します。テスターと修正チームによる短いデイリースタンドアップを行うことで、再テストを前に進め続けられます。
UATの証拠を記録する方法
メールやスプレッドシートに貼り付けたスクリーンショットは、レビューしにくく、紛失しやすく、画面間で何が起きたかを見落としがちです。テストの録画なら、より速く、より完全に記録できます：
テスターの画面を録画し、スクリプトを実行しながら各ステップをナレーションします。
証拠の列で録画をリンクし、重要なステップにはタイムスタンプを付けます。
欠陥対応に録画を活用して、開発者が「何が起きたか」を正確に把握できるようにします。
承認のために録画を監査証拠として保管します。
合格した録画を再利用して、新しいシステムのトレーニングを作成します。
UATテストスクリプト、テストケース、テストプランの違いは？
ドキュメント | それは何か |
|---|---|
テストプラン | 全体の方針：スコープ、スケジュール、環境、役割、入出基準 |
テストケース | 検証する単一の条件。多くの場合、テスターまたはQAが作成します。 |
UATテストスクリプト | 業務担当者が実際の業務シナリオをエンドツーエンドでテストするための、ステップバイステップの指示 |
テストサマリー レポート | テストサイクルの結果と、本番稼働に関する推奨 |
テストドキュメント一式については、テストドキュメンテーションのテンプレートをご覧ください。
テストスクリプトでUATを実行する方法
スコープと入場基準を合意します。例：完了したシステムテスト、安定したUAT環境。
要件と業務シナリオからスクリプトを作成し、例外も含めます。
テスト開始前にテストデータとユーザーアクセスを準備します。
テスターにスクリプト、証拠、欠陥プロセスをブリーフィングします。
スクリプトを実行し、証拠を記録しながら、欠陥を正確なステップに紐づけてログします。
欠陥を修正して再テストし、再テストの証拠を録画として残します。
結果を退出基準と照合して確認し、業務側の承認を取得します。
実装ドキュメンテーションやUATで動画を活用する方法については、動画でITプロジェクトの実装ドキュメンテーションとUATガイドを作成する方法をご覧ください。
UATテストスクリプトの形式
スプレッドシート：ステータス、テスター、優先度でフィルタリングできるため、多数のスクリプトに適しています。
ドキュメント：スクリーンショットや承認を含む詳細なシナリオに適しています。
テスト管理ツール：トレーサビリティ、ダッシュボード、欠陥の統合が必要な大規模なプログラムに適しています。
録画：証拠、欠陥、トレーニングとしての再利用に適しています。
UATテストスクリプトのベストプラクティス
システムメニューではなく、業務シナリオからスクリプトを書く。
実際にシステムを使う人を、スクリプト作成と実行に巻き込む。
期待結果を具体的で検証可能な形にする。
現実で問題を引き起こす例外をテストする。
各スクリプトの証拠を必ず記録する（失敗だけでなく）。
テスターだけでなく、業務オーナーから承認を得る。
よくあるミス（避けるべきこと）
手順が曖昧なこと。「請求書を処理する」など。
期待結果がないため、テスターが合格／不合格を判断できない。
ハッピーパスだけをテストする。
テスターが自分でテストデータを作ってしまう。
証拠がメールやチャットに散らばっている。
スクリプト、要件、欠陥の間にトレーサビリティがない。
UATテストスクリプトのチェックリスト
各スクリプトにID、タイトル、シナリオ、要件参照がある。
前提条件とテストデータが定義されている。
すべてのステップに1つのアクションと、具体的な期待結果がある。
例外がテストされている（ハッピーパスだけではない）。
各ステップについて、実測結果、ステータス、証拠が記録されている。
欠陥が正確なステップに紐づけられ、再テストされている。
テスターと業務オーナーが承認済みである。
Trupeerが、証拠付きでUATを実行するのを支援します
UATの課題 | Trupeerの支援 |
|---|---|
メール内のスクリーンショットはレビューしづらい | 各テスト実行を録画し、Trupeerがスクリーンショットと動画付きのステップバイステップのドキュメントに変換します |
欠陥を再現しにくい | 開発者は録画の中で、テスターが実際に何をしたかを正確に確認できます |
テスト証拠が散らばっている | すべてのテストドキュメントと動画を、検索可能な1か所に保管します |
スクリプト作成に時間がかかる | 重要なユーザーのシナリオ実行を録画し、生成された手順をスクリプトの下書きとして使えます |
トレーニングが遅れて始まる | 合格したテスト録画が、新しいシステムのトレーニングコンテンツになります |
TrupeerのUATドキュメンテーション自動化が、テスト録画を証拠とドキュメントに変える様子をご覧ください。
Genpactは、録画を最初に活用するこのアプローチを、全社規模のWorkday導入で採用しました。録画したプロセッションを、5つの言語で20のワークストリームにわたる500件超のトレーニング資料に変換し、3か月で40か国の140,000人の従業員に展開しました（通常は12か月）。Genpactの導入事例をお読みください。
無料のUATテストスクリプトテンプレートをダウンロード
Trupeerでテンプレートを開き、シナリオ、テストデータ、手順を追加して、テスターと共有してください。無料のUATテストスクリプトテンプレートを入手。
関連テンプレート
Fit-gap analysis template
ERP end user training plan template
よくある質問
UATテストスクリプトテンプレートとは？
ユーザー受け入れテストで業務担当者が従うステップバイステップの指示のための、すぐに使える形式です。シナリオ、前提条件、テストデータ、手順、期待結果と実測結果、ステータス、証拠、欠陥、承認をカバーします。
UATテストスクリプトには何を含めるべきですか？
ID、タイトル、シナリオ、要件参照を含むヘッダー、テスト詳細、前提条件、テストデータ、期待結果と実測結果を含む番号付き手順、ステータス、証拠、欠陥、再テスト結果、承認です。
UATテストスクリプトとテストケースの違いは何ですか？
テストケースは単一の条件を検証するもので、多くの場合QAが作成します。UATテストスクリプトは、業務担当者を実際の業務シナリオに沿ってエンドツーエンドで導くもので、複数の条件をカバーすることがよくあります。
UATテストスクリプトは何ステップ必要ですか？
通常は5〜20ステップで、1つの業務シナリオをカバーします。長いシナリオは複数のスクリプトに分割してください。
UATテストスクリプトは誰が作成しますか？
ビジネスアナリストまたはテストリードが、要件から下書きを作成することが一般的です。プロセスオーナーや主要ユーザーがレビューし、実際の業務を反映するようにします。
UATの証拠はどのように記録しますか？
テスターがスクリプトを実行している間に画面を録画し、証拠の列でタイムスタンプ付きで録画をリンクさせ、承認と監査のために結果と一緒に保管します。
UATテストスクリプトにはネガティブテストを含めるべきですか？
はい。差異、承認の欠落、無効なデータなどの例外をテストします。そこにこそ、本番稼働後に実際の問題が現れやすいからです。
ExcelにUATテストスクリプトテンプレートはありますか？
はい。スプレッドシートは、多数のスクリプトに適しており、ステータス、テスター、優先度でフィルタできます。Trupeerでテンプレートを開いてカスタマイズし、エクスポートするか、構造をExcelにコピーしてください。
WordまたはPDFにUATテストスクリプトテンプレートはありますか？
はい。詳細なシナリオと承認にはWordを使用し、監査記録用に承認済みスクリプトのPDFをエクスポートしてください。
UATテストスクリプトテンプレートは無料ですか？
はい。無料で登録してTrupeerでテンプレートを開き、カスタマイズしてエクスポートできます。
UATテストスクリプトはトレーニングに再利用できますか？
はい。合格したテストのスクリプトと録画は、設定済みのシステム内での実際の作業を説明しているため、トレーニングの強力な出発点になります。
UATの承認後はどうなりますか？
テストサマリーは本番稼働の判断に使われ、重大度の低い未解決の欠陥は追跡され、合格したシナリオは回帰テストとトレーニングに再利用されます。
