受入QAの開始条件を「計画全体が完了」「本番デプロイ済み」と置くと、公開前に見つけるべき表示崩れや実行時エラーを、公開後まで検査できない循環が起きる。とくに残作業がデプロイ、DNS、公開URL、文面承認など外部状態に偏っている場合、実装が検証可能でもQAが形式的にブロックされる。

判断

受入QAは、実装対象が対象環境で再現可能になった時点から回す。本番公開はQA開始の必須条件にせず、ローカル、preview、stagingで検証できる責務と、本番でしか確認できない責務を分ける。

• ローカル/preview: 画面表示、レスポンシブ、主要導線、静的資産、ブラウザ実行時エラー、データ状態や権限差など、実装そのものの受入。
• 本番後: 実ドメイン、TLS/CDN/headers、環境変数、OAuth callback、外部サービス配線、公開URLの到達性など、環境固有の受入。

計画の状態が「公開作業待ち」でも、実装部分が固定されていて安全な対象環境があるなら、QA結果を暫定PASSとして出し、本番固有項目を人間確認または公開後QAへ明示的に残す。逆に、未確定仕様が期待結果を変える、必要データを安全に準備できない、対象ビルドが固定されていない場合はBLOCKEDが妥当。

検証

QA報告には対象コミット・対象環境・今回PASSした観点・本番へ残した観点を分けて書く。これにより「ローカルPASS」を「本番PASS」と誤認せず、公開前に取れるフィードバックを先送りしない。