自動QAで前提データを毎回UI操作で作らない。判断基準は「データ作成そのものが検証対象か」: 登録/注文作成の検証ならUI操作としてシナリオに含め、注文済みからのキャンセル検証なら注文は事前fixture/APIで用意する。前提データまでUIで作るとシナリオが長くなり、準備部分の失敗と本来のQA失敗を区別できなくなる。準備手段の優先順位は、宣言済みのQAデータコマンド→仕様に記載のデータ要件→既存seed/fixture/factory/E2Eセットアップ→テスト用/管理API→UI操作、の順で既存を再利用する。隔離運用: QA実行ごとに一意な run ID を発行し作成データすべてに付与、cleanupはその run ID だけを対象にして他のテストデータを巻き込まない。共有staging環境ではQA専用テナント/アカウント＋run ID＋TTL/cleanup必須、メール・決済・外部通知はsandboxへ向ける。本番では原則データ作成せず読み取り専用スモークと事前用意のsyntheticアカウントに限り、書き込みは明示承認必須。安全な準備手段が無い場合は推測でDBへ直接クエリを書かず「データ準備手段なし」でブロックし、fixture基盤の追加を実装側へ依頼する。結果ステータスは多値化して失敗の帰属を分ける(合格/製品バグ/シナリオ側の問題/データ準備不能/環境不能/cleanup失敗)——データ準備やシナリオの失敗を製品バグに誤帰属しないため。cleanupは成否に関わらず実行し、残存確認までを1QA単位とする。