AIでE2Eテストのシナリオを作る方法｜ユーザー操作から考える

E2Eテストのscenarioは画面部品の一覧ではなく、利用者の目的と開始状態から作ります。成功する操作だけでなく、入力誤り、権限、network、空状態など、利用者が遭遇する分岐も別scenarioで扱います。AIにscenario案を作らせた後、実際の画面にあるrole、label、textを使って操作し、期待結果を実行して確かめます。未実行のテスト案を「確認済み」と扱ってはいけません。

User goalからJourneyを定義する

まず「誰が、何を達成したら完了か」を書きます。例として「既存accountでログインし、一覧から一件を開いて状態を更新する」は複数画面を跨ぐUser Journeyです。開始時のaccount、record、permission、初期状態を明記し、完了をURL、visible status、保存結果などで観測できる形にします。

表は横にスクロールできます

Field	記載すること	例
User goal	利用者が達成する仕事	依頼を登録できる
Persona / role	操作する権限	管理者 / 一般利用者
Preconditions	開始状態とfixture	test account、未処理record
Actions	画面上の操作	form入力、送信
Expected result	利用者に見える結果	完了message、一覧行
Failure path	失敗時の挙動	validation、権限、network
Evidence	実行結果の保存	trace、screenshot、log

これはschema例です。実画面にないroleや状態を追加せず、利用者のcontractを確認してからscenarioへ落とします。正常系と失敗系を一つの長いscenarioへ詰めず、原因を特定できる単位に分けます。

ScenarioとTest caseを分ける

Scenarioは利用者の目的を表し、test caseは特定条件の検証を表します。一つのscenarioから正常系、必須field欠落、重複送信、permission不足など複数test caseができます。すべての組合せを網羅しようとせず、Reader Jobやdata safetyを壊す分岐から優先します。

表は横にスクロールできます

Case	Start state	Action	Expected
success	必須dataあり、許可あり	submit	一度だけ保存され、完了状態を表示
invalid	必須data不足	submit	validationが見え、保存なし
no permission	閲覧のみ	update	操作不可と理由を表示
network failure	APIがerrorを返す	retry / return	二重保存せず次Actionを示す

「保存なし」など期待結果は、アプリの契約を確認して決めます。期待が不明なら、AIに決めさせずscenarioをDraftとして残します。

Locatorとwaitを利用者視点で選ぶ

Playwrightはrole、label、textなど利用者に見える意味に沿うlocatorを推奨しています。CSS classやDOM構造に過度に依存すると、表示変更でtestだけ壊れやすくなります。ただしaccessible nameが曖昧だったり同じ名前のbuttonが複数ある場合は、test用data attributeなどを既存方針に沿って使い分けます。

画面の表示は非同期で変わるため、一定時間の固定waitだけに頼らず期待する状態を待ちます。PlaywrightのWeb-first assertionは、対象要素が期待状態になるまで再試行する仕組みがあります。timeout、retry条件、失敗時traceやscreenshotはtest suiteの既存設定に合わせてください。これはPlaywrightの仕様であり、他frameworkの挙動とは区別します。

AIへの依頼Prompt

User goal：[利用者の仕事]

Role / permission：[確認済みのrole]

Precondition：[開始状態、fixture]

User-visible steps：[実画面の操作]

Expected result：[各stepで見える状態]

Failure cases：[優先する例外]

Evidence：[保存するtrace/screenshot]

既存route、label、status、permission情報：[資料]

画面にない要素、未確認の期待値を作らず、

Normal / Error scenarioを分けて出してください。

Implementation internalsより利用者の目的と表示結果を優先。

AIにDOMや画面録画を渡す場合は、個人dataや認証tokenを隠し、必要範囲だけ共有します。Promptに本番ユーザーの実メールやsecretを入れず、test fixtureへ置き換えます。

実行前に決める

• Test dataを作成・削除する手順と、共有環境への影響。

• Login、MFA、権限の準備方法。

• 外部送信、課金、メール、通知などのside effect。

• Retry時に重複処理が起きるか。

• 他testと同時実行してdataが競合しないか。

• 実行後に状態を戻す方法。

E2E testは本物のexternal serviceへ接続すると、送信や請求などの実処理を起こす可能性があります。Network mockやstagingを使うかは既存strategyに合わせ、環境設定のないままProduction操作を実行しないでください。認証状態を保存するfileは共有やcommitの対象外です。

Coverageと失敗時の診断

Scenario表には「何を見たか」を記録します。主要な利用者目標、permission差、empty state、重要error、responsive表示など、体験に直接影響する箇所を含めます。test数を増やしても重要journeyが抜けていれば十分とは言えません。

失敗時は、step、locator、期待値、実値、console、network、traceを使って原因を分けます。Application bug、test data不整合、locatorの壊れ、external serviceの一時障害を区別し、期待値を緩めて通すだけの修正は避けます。同じ一時失敗が複数回出てもretryで隠さず、flakyの根本要因を探します。

AIものさしの判断

利用者の目標とvisible resultが一続きに定義できたら、E2E scenarioとして実装できます。内部componentの呼び出しだけを追うtestでは、読者の完了を確認できないことがあります。AI候補は実画面・permission・data contractと照合し、実行結果、未実行範囲、失敗原因を分けて記録してください。

Fixtureと環境を固定する

E2Eが毎回違う結果になる場合、画面ではなくtest dataの競合や環境状態が原因かもしれません。実行ごとのfixtureを使い、ユーザー、権限、レコード、初期状態を明示します。共有環境で並列実行すると同じrecordを同時更新することがあるため、独立データを割り当てるか既存runnerの分離機能を使います。

表は横にスクロールできます

Data / side effect	制御方法の例	確認事項
account	専用test user	permissionとMFA
record	run ID付きfixture	他testと独立
email / notification	sandbox mailbox、stub	実宛先へ送らない
payment / external action	mock / test mode	chargeが起きない
cleanup	teardownまたは期限付きdata	productionを消さない

実際に利用する方法はプロジェクトのtest strategyで確認します。この表の方式がすべての環境に存在するとは限りません。

Assertionを利用者結果に合わせる

「ボタンを押せた」だけでは、仕事が完了したとは言えません。送信後のconfirmation、保存済みrecord、表示状態、permissionで隠れる操作など、利用者に見える結果を確認します。内部実装へ強く依存したassertionだけで合格にせず、重要な業務条件をAPIやdata testで補うか検討します。

Failure時にはスクリーンショットだけでなく、step、URL、console、request、response、traceを残します。証拠に秘密情報が含まれないようmaskingし、retentionとアクセス範囲は既存ルールに従ってください。

実行結果を報告する

Test runは対象branch、環境、browser、fixture、実行時刻を記録します。実行に成功しても、scenarioのすべてのassertionが通ったか、retry後に通ったか、skipしたtestがないかを確認します。テストが未実行、外部依存で保留、または実環境の権限がなく確認できない場合は、PASSと混ぜず明記します。

Screenshotやtraceは失敗の原因調査に役立ちますが、個人データ、session token、内部URLを含む場合があります。保存先、期限、閲覧者を決め、外部共有やrepo commitへ持ち込まないようにします。