UATとは？ユーザー受け入れテストの進め方とシステムテストとの違い｜成果物の実物つき

テストは、作る前に決めたことを、作ったあとに逆の順番で確かめていきます。V字モデルで見ると、UATは「要件定義（業務で何をしたいか）」と向き合う、いちばん最後の工程です。

flowchart TD
    R[要件定義<br>業務で何をしたいか] -.確かめる.-> U[受け入れテスト UAT<br>利用者が業務で使えるか]
    B[基本設計<br>システムの動き] -.確かめる.-> S[システムテスト<br>仕様どおり全体が動くか]
    D[詳細設計<br>部品の作り] -.確かめる.-> I[結合テスト<br>部品をつないで動くか]
    C[実装] --> T[単体テスト<br>部品1つが動くか]
    R --> B --> D --> C
    T --> I --> S --> U

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、小さな社内向けの経費申請アプリを Flask 3.1.3（Werkzeug 3.1.9・Python 3.13.18・SQLite）で作り、127.0.0.1 のポートだけで起動しました。要件定義の8項目を確かめるシステムテストを pytest 9.1.1 で、業務の流れに沿ったUATシナリオ7本を Playwright 1.63.0（Python 版）と Chromium 153.0.8010.12（ヘッドレス）で流し、修正前（v1）と修正後（v2）の合否を比べています。シナリオ・観点表・合否基準・不具合票は、この題材のために書いた実物です。受け入れテストの定義と種類は JSTQB Foundation Level シラバス（Version 4.0）と ISTQB Glossary、Playwright の書き方は公式ドキュメントで確かめました。図は mermaid-cli 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

UATとは（ユーザー受け入れテストの意味）

この節では、UATという言葉の意味と、似た言い方との関係が分かります。

UATは User Acceptance Test（または User Acceptance Testing）の略で、日本語では「ユーザー受け入れテスト」「ユーザー受入テスト」と呼びます。 完成したシステムを、それを使う部門の人が自分の業務の流れで操作し、「このシステムを受け取って業務に使い始めてよいか」を判断するテストです。

国際的なテスト資格の用語集（ISTQB Glossary）は、受け入れテスト（acceptance testing）を「システムを受け入れるかどうかを判断することに焦点を当てたテストレベル。通常はユーザーや顧客が行う」という趣旨で定義しています。日本の JSTQB のシラバスでも、受け入れテストはテストレベルの1つで、その代表的な形がユーザー受け入れテストです。

• 受け入れテスト：受け入れるかを決めるテスト全体の呼び名。運用・契約・規制の観点のものも含む。
• ユーザー受け入れテスト（UAT）：そのうち、利用者が業務で使えるかを確かめるもの。検索で「UAT」と書かれているのは、ほとんどがこれ。
• 受入テスト・検収テスト：同じ意味で使われることが多い言い方。ただし「検収」は契約上の受け取りの手続きを指し、テストそのものとは分けて考えます（後の節で扱います）。

同じ「UAT」でも、別のものを指す場合があります。開発の環境名として dev・stg・uat・prod と並ぶときの「uat」は「UATを行うための環境」のこと、ゲーム開発で Unreal Engine の話に出る UAT は Unreal Automation Tool（ビルドの自動化ツール）のことで、この記事の主題とは別物です。

UATの目的と、誰が行うか

この節では、UATを行う目的と、利用部門・開発側それぞれの役割が分かります。

UATの目的は3つです。業務要件とのずれを見つけること、リリース後の混乱を減らすこと、そして受け入れるかどうかを決めることです。 上位の解説記事でも共通して挙げられている3点で、手元の申請アプリでも、3つ目の「決める」ために最初の2つが要ることが分かりました。

参加する人と役割

開発側がUATを代わりに行うと、UATの意味が薄れます。 開発側は仕様を知っているため、仕様どおりの操作をしてしまい、業務の人が実際にする入力（カンマ付きの金額など）を試しません。開発側が自動化でシナリオを流す場合も、シナリオの中身と合否の判断は利用部門が持ちます。

V字モデルで見るテスト工程の違い（単体・結合・システム・受け入れ）

この節では、単体テストから受け入れテストまでの4つの工程が、それぞれ何を確かめるのかが分かります。

テスト工程は、下流ほど小さな部品を、上流ほど大きな目的を確かめます。 冒頭の図のように、受け入れテストは要件定義と、システムテストは基本設計と、結合テストは詳細設計と対になります。

工程ごとの設計書とテストの対応や、W字モデルとの違いは、関連記事「V字モデルとは？設計とテストの工程対応表とW字モデルとの違い」で扱っています。

UATとシステムテストの違い（8件合格でもUATで2件不合格）

この節では、受け入れテストとシステムテストの違いを、同じアプリで両方を実行した結果で確かめられます。

システムテストは「書かれた仕様どおりか」、UATは「その仕様で業務が回るか」を確かめます。 仕様そのものが業務とずれていると、システムテストは全部合格でも、UATで不合格になります。

題材：社内の経費申請アプリ

手元で作ったのは、営業部の佐藤さんが経費を申請し、田中課長が承認（5万円以上は鈴木部長も承認）、経理の山田さんが支払い対象を確かめる、という小さなアプリです。要件定義書には次の8項目を書き、開発側はこの8項目をシステムテストとして pytest で確かめました。

$ APP_VER=1 python3 -m pytest -p no:cacheprovider -v test_system.py
test_system.py::test_R01_申請すると課長承認待ち PASSED                   [ 12%]
test_system.py::test_R02_金額は半角数字のみ PASSED                       [ 25%]
test_system.py::test_R03_5万円以上は部長承認へ PASSED                    [ 37%]
test_system.py::test_R04_5万円未満は課長承認で完了 PASSED                [ 50%]
test_system.py::test_R05_自分の申請は承認できない PASSED                 [ 62%]
test_system.py::test_R06_他部署の申請は見えない PASSED                   [ 75%]
test_system.py::test_R07_差し戻し理由は必須 PASSED                       [ 87%]
test_system.py::test_R08_差し戻すと状態が差し戻し PASSED                 [100%]
8 passed in 0.14s

同じ v1 に、利用部門の目線で書いたUATシナリオ7本を Playwright で流した結果が次です。

$ python3 uat_run.py 1
server pid 10214
chromium 153.0.8010.12
UAT-01 PASS 0.47s 交通費を申請し、課長承認後に経理の支払い対象に出る
UAT-02 FAIL 0.27s 領収書の金額をカンマ付き（12,800）で入れて申請できる 申請が登録されない。画面の表示：金額は半角数字で入れてください。
UAT-03 FAIL 0.46s 差し戻された申請を修正して再申請できる 差し戻し後の申請に「修正して再申請」が無い（新規で出し直すしかない）
UAT-04 PASS 0.59s 5万円以上の出張費は課長→部長の順で承認される
UAT-05 PASS 0.26s 課長は自分の申請を承認できない
UAT-06 PASS 0.27s 他部署の人は申請を見られない
UAT-07 PASS 0.45s 差し戻し理由が空なら差し戻せない
server stopped 10214 -15
合格 5/7  合格率 71%

不合格の2件は、どちらもシステムテストでは見つかりません。R-02 は「金額は半角数字のみ」と書かれた仕様を正しく守っており、差し戻した申請を直す機能は、要件定義書にそもそも書かれていなかったからです。仕様の漏れや、仕様と業務のずれを見つけられるのはUATだけ、というのが手元で確かめた一番の違いです。

システムテストの観点そのものは、関連記事「システムテストとは｜結合テストとの違いと観点一覧」で扱っています。

受け入れテストの種類（UAT・運用・契約・規制・アルファ・ベータ）

この節では、受け入れテストにどんな種類があり、UATがその中のどれなのかが分かります。

JSTQB・ISTQB のシラバスでは、受け入れテストの代表的な形として、ユーザー受け入れテスト・運用受け入れテスト・契約による受け入れテスト・規制による受け入れテスト・アルファテスト・ベータテストが挙げられています。 社内システムでは、UATと運用受け入れテストを組み合わせることが多くなります。

「BAT（業務受け入れテスト）」という言い方もありますが、指す範囲は組織によって違い、UATのうち業務の流れの確認を指して使われることがあります。言葉より「誰が・何を確かめて・何を決めるか」をそろえるほうが、関係者の間で話が食い違いません。

UATの進め方（7つの手順）

この節では、UATを計画してから合否を決めるまでの流れが、手順ごとに分かります。

UATは「始める前に合否基準を決める」ことから始まり、「基準に照らして判定する」ことで終わります。 間の作業は、すべてその判定のための材料集めです。

手順1〜2の「計画」をどう書くか（開始基準・終了基準の書き方）は、関連記事「テスト計画書の書き方と項目一覧｜開始基準・終了基準のテンプレート」で扱っています。

UATの計画と合否基準（判断表つき）

この節では、UATの開始条件と合否基準を、申請アプリで実際に書いた形で確かめられます。

合否基準は、UATを始める前に「数」で決めます。 終わってから決めると、残った不具合を前に「これくらいならよいか」という話になり、判断が人によって変わります。

申請アプリのUAT計画（抜粋）

■ UAT計画書（経費申請アプリ v1）
対象業務   ：経費の申請・承認・差し戻し・再申請・支払い対象の確認
対象外     ：会計システムへの連携（運用受け入れテストで扱う）
実施者     ：営業部 2名（申請者役・課長役）、経理 1名
判定者     ：経理部長
期間       ：5営業日（再テスト 2営業日を含む）
開始条件   ：システムテストの合格率100%、重大度Aの残件 0、UAT環境とデータの準備完了
合否基準   ：シナリオ実施率100%、合格率95%以上、
             重大度A（業務が止まる）0件、重大度B（回避はできるが手間が大きい）0件、
             重大度C（見た目・文言）は件数と修正期限を合意すれば可
エビデンス ：シナリオごとの画面記録（PNG）と実行ログ

判定の順番

1. 1全シナリオを実施したか → していなければ判定しない未実施が残ったまま合否を出さない
2. 2重大度Aが残っているか → 残っていれば不合格業務が止まる・金額が狂う・権限が漏れる
3. 3重大度Bが残っているか → 回避手順と期限が無ければ不合格業務は回るが手間が大きい
4. 4合格率が基準以上か → 下回れば不合格この計画では95%以上
5. 5重大度C・要望の扱いを合意したか → 合意できれば合格次の版で直すものを一覧にして残す

判断表：この結果なら受け入れるか

申請アプリの2件は、どちらも「業務は回るが手間が大きい」ので重大度Bとしました。カンマを消せば申請はでき、差し戻しは新規に出し直せば済みます。それでも、毎月数百件の申請で同じ手間が出ると考えると、受け入れ前に直す判断になります。

UATシナリオの書き方（申請アプリの実物）

この節では、UATシナリオを画面単位ではなく業務の流れで書く方法が、実際に書いた7本で分かります。

UATシナリオは「誰が・何のために・どの順で操作し・どうなれば合格か」を1本にまとめたものです。 1つの画面の入力項目を全部試すのはシステムテストの仕事で、UATでは仕事の始まりから終わりまでを通します。

1本のシナリオの書き方（UAT-03 の全文）

ID        ：UAT-03
シナリオ  ：差し戻された申請を修正して再申請できる
業務上の目的：利用日の間違いなど小さな誤りを、出し直さずに直せること
前提      ：申請者=佐藤（営業部）、課長=田中。佐藤の申請（交通費 9,800円）が「課長承認待ち」
手順      ：1. 田中でログインし、申請を開く
            2. 差し戻し理由に「領収書の日付と利用日が違います」と入れて差し戻す
            3. 佐藤でログインし、同じ申請を開く
            4. 「修正して再申請」から利用日を 2026-10-19 に直して申請する
期待結果  ：手順2のあと状態が「差し戻し」になり、理由が表示される
            手順4のあと、同じ申請番号のまま状態が「課長承認待ち」に戻る
実際の結果：（実施者が書く）
合否      ：合格／不合格
エビデンス：UAT-03.png（手順4の画面）
実施者・日：

• 期待結果は、判定できる言葉で書く：「正しく表示される」ではなく「状態が『課長承認待ち』に戻る」。誰が見ても合否が同じになる書き方にします。
• 例外の業務を入れる：差し戻し・承認者が自分自身・他部署から見る、など。不具合は例外の流れに集まります。
• データは業務の形で：手元では UAT-02 の「12,800」が、利用者が領収書を見て入れる形そのものでした。開発側が考えたデータでは出てこない入力です。

シナリオの雛形や、受注管理を題材にしたシナリオ例は、関連記事「受入テストの観点チェックリストとUATシナリオの書き方」でも扱っています。この記事はUATの全体像と実行結果、あちらは観点35項目と検収書の項目に重点を置いています。

UATの観点表（何を確かめるか）

この節では、UATのシナリオを書くときに漏らしやすい観点と、申請アプリでそれをどのシナリオで確かめたかが分かります。

観点表は、シナリオの漏れを見つけるための表です。 観点ごとに「どのシナリオで確かめたか」を書き、空いている行があれば、シナリオを足すか、対象外と合意します。

シナリオを実施する前に、実施者が確かめておく項目は次の4つです。

• 1ログインできるユーザーが役割の数だけある申請者・課長・部長・経理・他部署。1人で全部の役をしない
• 2環境の版がUAT計画の版と同じ画面に版の表示（手元では v1・v2）を出しておくと取り違えない
• 3前提のデータがそろっている「課長承認待ちの申請が1件ある」など、シナリオの前提を満たしてから始める
• 4エビデンスの残し方を決めてある画面の記録のファイル名をシナリオIDにそろえる（UAT-03.png など）

不具合票の書き方と、不具合・要望の切り分け

この節では、UATで見つけた問題を不具合票に書く形と、「不具合か要望か」を分ける考え方が分かります。

UATで出る指摘は、不具合（決めたとおりに動かない）と要望（決めたことを変えたい）に分けます。 混ぜたまま数えると、合否の判定も、費用と期限の話し合いも食い違います。

申請アプリで書いた不具合票（2件）

票番号    ：UAT-BUG-001
シナリオ  ：UAT-02 領収書の金額をカンマ付き（12,800）で入れて申請できる
環境・版  ：UAT環境 v1 / Chromium 153
再現手順  ：1. 佐藤でログイン  2. 新規申請  3. 金額に「12,800」と入れて「申請する」
期待結果  ：申請が登録され「課長承認待ち」になる
実際の結果：登録されず「金額は半角数字で入れてください。」と表示される
頻度      ：毎回（5回中5回）
重大度    ：B（カンマを消せば申請できるが、毎回の手間になる）
種別      ：要件の漏れ（要件R-02は「半角数字のみ」。業務の入力の形と合わない）
エビデンス：UAT-02.png
対応      ：カンマ・全角数字・「円」を取り除いてから数値にする（v2）

票番号    ：UAT-BUG-002
シナリオ  ：UAT-03 差し戻された申請を修正して再申請できる
環境・版  ：UAT環境 v1 / Chromium 153
再現手順  ：1. 田中で申請を差し戻す  2. 佐藤で同じ申請を開く
期待結果  ：「修正して再申請」がある
実際の結果：画面に修正の手段が無く、新規申請で出し直すしかない
重大度    ：B（出し直しで回避できるが、申請番号が変わり経理の照合が手間になる）
種別      ：要件の漏れ（差し戻し後の扱いが要件定義書に無い）
エビデンス：UAT-03.png
対応      ：差し戻し状態の申請に限り、申請者本人が修正して再申請できるようにする（v2）

不具合か要望かを分ける問い

申請アプリの2件は、書かれた仕様どおりには動いていたため、厳密には「要件の漏れ」です。こうした指摘を「不具合」として開発側にだけ渡すと、誰の費用で直すかの話がこじれます。票の「種別」の欄で分けておくと、判定会議で扱いを決めやすくなります。重大度の決め方と票のテンプレートは、関連記事「バグ報告の書き方｜コピペ用テンプレートと重大度判定表」で扱っています。

UAT環境（ステージング）の考え方とテストデータ

この節では、UAT環境をどう用意するか、本番や開発の環境とどう分けるかが分かります。

UAT環境は「本番に近い構成で、本番とは切り離した環境」です。 呼び名は組織によって違い、ステージング（stg）と同じものを指すことも、stg とは別に uat という環境を置くこともあります。

• 版を固定する：UAT中に開発側が新しい版を勝手に入れると、合格した結果が無意味になります。入れ替えは不具合の修正を入れる時だけにし、版を記録します。手元では画面の上に「v1」「v2」を出し、エビデンスの画像に版が写るようにしました。
• データを分ける：手元では版ごとに別の SQLite ファイル（uat_v1.sqlite・uat_v2.sqlite）を使い、修正前の結果を上書きしないようにしました。
• 本番データを使うなら加工する：氏名・連絡先・口座などの個人情報は、置き換えるか、業務の形を保った架空のデータを作ります。
• 外部への送信を止める：メール・決済・会計システムへの連携は、検証用の宛先か、モック（偽の受け口）に向けます。UAT環境から本物の取引先にメールが届く事故は、設定の取り違えで起こります。
• 本番との違いを一覧にする：サーバーの台数・外部連携の宛先・データ量など、本番と違う点を書き出しておくと、UATで出なかった問題を本番で見たときの切り分けが速くなります。

PlaywrightでUATシナリオを自動で流す（実行結果）

この節では、UATシナリオを Playwright で自動実行し、修正後の再テストを短い時間で済ませた結果が分かります。

自動化が効くのは、UATの「判断」ではなく「再テスト」です。 1回目は利用部門が手で操作して気づきを集め、合意したシナリオを自動化しておくと、修正のたびに全シナリオを数秒で流し直せます。

シナリオをコードにした例（UAT-03）

シナリオの手順をそのままコードにしています。画面の要素は、利用者が見ている言葉（ラベル・ボタンの名前）で探す書き方（get_by_label・get_by_role）にすると、シナリオとコードの対応が読み取りやすくなります。

def s03(p):
    login(p, "sato"); i = apply(p, "9800", note="領収書の日付違い")
    login(p, "tanaka"); p.goto(f"{B}/req/{i}")
    p.get_by_label("差し戻し理由").fill("領収書の日付と利用日が違います")
    p.get_by_role("button", name="差し戻す").click()
    login(p, "sato"); p.goto(f"{B}/req/{i}")
    link = p.get_by_role("link", name="修正して再申請")
    assert link.count() == 1, "差し戻し後の申請に「修正して再申請」が無い（新規で出し直すしかない）"
    link.click(); p.get_by_label("利用日").fill("2026-10-19")
    p.get_by_role("button", name="申請する").click()
    assert status(p, i) == "課長承認待ち"

失敗したときの文言は、不具合票の「実際の結果」にそのまま写せる言葉にしておきます。シナリオごとに画面の記録（PNG）も保存し、エビデンスにしました。

def run(sid, title, fn, p):
    t0 = time.perf_counter()
    try:
        fn(p); ok, note = True, ""
    except Exception as e:
        ok, note = False, str(e).splitlines()[0][:120]
    p.screenshot(path=f"{OUT}/{sid}.png")
    results.append({"id": sid, "title": title, "result": "合格" if ok else "不合格",
                    "sec": round(time.perf_counter() - t0, 2), "note": note})

修正後（v2）の再テスト

UAT-BUG-001・002 を直した v2 に対し、システムテストと全シナリオを流し直しました。直した2本だけでなく、合格していた5本も流すのは、修正でほかが壊れていないかを確かめるためです。

$ APP_VER=2 python3 -m pytest -p no:cacheprovider -q test_system.py
8 passed in 0.15s
$ python3 uat_run.py 2
server pid 10385
chromium 153.0.8010.12
UAT-01 PASS 0.51s 交通費を申請し、課長承認後に経理の支払い対象に出る
UAT-02 PASS 0.25s 領収書の金額をカンマ付き（12,800）で入れて申請できる
UAT-03 PASS 0.66s 差し戻された申請を修正して再申請できる
UAT-04 PASS 0.63s 5万円以上の出張費は課長→部長の順で承認される
UAT-05 PASS 0.23s 課長は自分の申請を承認できない
UAT-06 PASS 0.26s 他部署の人は申請を見られない
UAT-07 PASS 0.48s 差し戻し理由が空なら差し戻せない
server stopped 10385 -15
合格 7/7  合格率 100%

サーバーの起動から Chromium の終了までを含めても、1回の実行は v1 で4.6秒、v2 で4.7秒でした（time コマンドの real）。手で7本を操作すると、5人分のログインの切り替えを含めて数十分かかります。再テストのたびにこの差が積み重なるのが、自動化の効き目です。

一方で、UAT-02 の「カンマ付きで入れる」という気づきは、自動化からは出てきません。最初にシナリオを書いた人が、領収書を見ながら入力する業務を知っていたから出てきたものです。自動化は人の気づきを置き換えるものではなく、一度見つけた気づきを毎回確かめ続けるための仕組みと考えます。Playwright の書き方・CIでの実行は、関連記事「Playwright入門｜E2Eテストの書き方とCI実行まで実行結果つきで解説」で扱っています。

UATでよくある失敗とつまずき（原文つき）

この節では、UATの進め方でよくある失敗と、自動化で出たエラーの原文と直し方が分かります。

UATの失敗の多くは、テストそのものではなく「段取り」から起きます。 上位の解説記事でも、期間不足・画面確認だけで終わる・判定基準が曖昧、が共通して挙げられています。

自動化で出たエラーの原文と直し方

2つ目は、UAT-05（自分の申請に承認ボタンが出ない）のように「出ないことが正しい」シナリオで、うっかり click を書いたときにも出ます。出ないことを確かめるときは、要素の数が0であることを確かめる書き方にします。

よくある質問

Q. UATとは何の略ですか？ A. User Acceptance Test（User Acceptance Testing）の略で、日本語ではユーザー受け入れテストと呼びます。完成したシステムを利用者が業務の流れで使い、受け入れてよいかを決めるテストです。

Q. 受け入れテストとUATは同じですか？ A. ほぼ同じ意味で使われますが、厳密には受け入れテストのほうが広い言葉です。受け入れテストには、UATのほかに運用受け入れテスト・契約による受け入れテスト・規制による受け入れテスト・アルファテスト・ベータテストがあります。

Q. UATとシステムテストの違いは何ですか？ A. システムテストは開発側が「要件定義書・設計書どおりに動くか」を確かめ、UATは利用部門が「業務で使えるか」を確かめます。手元の申請アプリでは、システムテストは8件すべて合格でしたが、UATでは仕様の漏れが原因で7本中2本が不合格になりました。

Q. UATは誰が行いますか？ A. 発注側の利用部門（実際に使う人）が操作し、業務の責任者が合否を決めます。開発側は環境とデータの準備、操作の説明、不具合の修正を担当します。

Q. UATの期間はどれくらい取りますか？ A. シナリオの数と、修正後の再テストの回数で決まります。最初の実施に加えて、少なくとも1回の再テストの期間を計画に入れておきます。手元の申請アプリの計画では、5営業日のうち2営業日を再テストに当てています。

Q. UATの合否基準はどう決めますか？ A. 始める前に、重大度別の残件数（重大度Aは0件など）、シナリオの実施率と合格率を数で決め、利用部門の責任者と開発側で合意します。終わってから決めると判断が人によって変わります。

Q. UATと検収の違いは何ですか？ A. UATはテストの工程、検収は契約にもとづいて成果物を受け取ったと確認する手続きです。UATの合格が検収の条件になることが多いものの、検収の形式は契約で決まります。

Q. UAT環境とステージング環境は同じですか？ A. 同じものを指すこともあれば、stg とは別に uat という環境を置く組織もあります。どちらの場合も、本番に近い構成で本番とは切り離し、リリース候補の版を固定して使う点は共通です。

Q. UATは自動化できますか？ A. シナリオの実行と再テストは自動化できます。手元では7本のシナリオを Playwright で約5秒（起動と終了を含めて4.7秒）で流せました。ただし、業務に合っているかの気づきと受け入れの判断は、利用部門の人が行います。

Q. UATで見つかった問題は全部直してからリリースしますか？ A. 合否基準しだいです。重大度Aは直してから、重大度Cや要望は件数と修正の期限を合意したうえで、次の版に回すことがあります。

Q. アジャイル開発でもUATは行いますか？ A. 行います。スプリントごとにプロダクトオーナーが受け入れ基準に照らして確かめる形や、リリース前にまとめて利用部門が確かめる形があります。いつ・誰が・何を基準に受け入れるかを決めておく点は同じです。

まとめ

• UATは、利用者が業務の流れで使い、受け入れてよいかを決めるテスト。V字モデルでは要件定義と対になる、最後のテスト工程です。
• システムテストとは問いが違う。申請アプリでは、システムテスト8/8合格でもUATは5/7で、仕様の漏れが2件見つかりました。
• 合否基準は始める前に数で決める。重大度別の残件数と合格率を合意し、判定の順番どおりに判断します。
• シナリオは業務の始まりから終わりまでを1本に。例外の流れと、利用者がふだん入れる形のデータを入れます。
• 自動化は再テストに効く。7本を約5秒で流し直せましたが、気づきと受け入れの判断は人が行います。

参考・出典

確認日はいずれも 2026年10月29日です。

• JSTQB「ソフトウェアテスト技術者資格認定 Foundation Level シラバス Version 4.0」2.2.1 テストレベル：https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf
• ISTQB「ISTQB Glossary」acceptance testing・user acceptance testing：https://glossary.istqb.org/
• Playwright「Locators」（Python）：https://playwright.dev/python/docs/locators
• Playwright「Assertions」（Python）：https://playwright.dev/python/docs/test-assertions
• Playwright「Screenshots」（Python）：https://playwright.dev/python/docs/screenshots
• Flask「Testing Flask Applications」：https://flask.palletsprojects.com/en/stable/testing/
• pytest「How to use fixtures」：https://docs.pytest.org/en/stable/how-to/fixtures.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。