qa-execution

実ユーザー視点の QA 実行

実際のユーザーが体験するように製品の QA を行います。ペルソナが製品の公開インターフェースを通じて一連の操作を進め、使いにくさを感じ、限界に直面し、起きたことを報告します。これはドッグフーディングであり、スクリプト化されたテストの実行ではありません。セッションそのものが作業であり、継続的に更新される QA ドキュメントツリーにその記録を残します。

すべてのセッションで、次の 3 つを必ず守ります。

1. ペルソナになりきります。 すべての操作と検証は、実際のユーザーがアクセスできる画面を通じて行います。開発者ツールでの近道、期待される動作を判断するためのコード閲覧、停滞を覆い隠す修正は禁止です。
2. 楽観視ではなく、証拠を示します。 Pass とは、期待される結果を目視で確認し、独立した読み取り経路でも確認でき、更新後も維持され、証拠が記録されている状態です。楽観的 UI は確認にはなりません。
3. 記録に反映しなければ、実施したことにはなりません。 すべてのセッションでツリーを更新します。シナリオファイルの判定、バグレジストリ、セッションの振り返りを記載した日付入りレポートが対象です。

入力

• qa-docs-path（任意）：継続的に更新される QA ドキュメントツリーのルートです。デフォルトは docs/qa/ です。このツリーはこのスキルの記憶であり、出力先はここだけです。一時ディレクトリは使用しないでください。存在しない場合は、まず qa-report を実行してください。ツリーの管理と初期設定は qa-report が担当します。

手順

計画されたスモーク、対象限定、または全範囲のいずれかを選びます。関連する手順やスキーマのセクションだけを読み、変更のない動作については現在の証拠を再利用します。変更された操作の範囲が小さい場合、すべてのツアーや境界条件を網羅したり、全工程をもう一度実施したりする必要はありません。

ステップ 1 — ツリー、範囲、前提条件を確定する

• 次の順に読みます。<qa-docs-path>/README.md（エントリーポイント、開発サーバーのコマンド、領域コード）、対象範囲の scenarios/ ファイル、関連する未解決の bugs/、今サイクルのチャーターです。このツリーが記憶です。これを読まずに実行すると、この設計が解消しようとしている重複を再び生み出します。
• 範囲：ブランチ／PR の実行では、ユーザーに見える差分が影響する操作と、共有動作に回帰のおそれがある場合は隣接するカナリアを対象にします。ユーザーに見える変更がない場合は、その旨を報告して終了します。リリース／全範囲の実行では、サイクル計画で対象とされた操作を網羅します。
• 前提条件：該当する前提条件を満たし、既存の必須チェックに合格していることを確認します（現在の証拠を再利用し、対象を絞った調査の前に無関係なテストスイートが完了するのを待つ必要はありません）。また、製品が本番環境と同等のビルドで利用可能であること（実際の開発サーバー、実際の認証、モックなし）が必要です。利用できない場合は、具体的な不足内容を明示して終了します。
• 完了条件： 範囲が確定し、すべての前提条件が満たされているか、不足内容が明示されていること。

ステップ 2 — マトリックスを作成し、すぐにレポートを作成する

• references/status-and-reporting.md を読みます。6 値のステータス列挙型とレポートのライフサイクルは、ここに記載されています。
• 計画されたチャーターから、セッションのマトリックスを作成します。ペルソナ × 操作 × ツアー × 時間枠をリスク順に並べます。対象範囲の操作にチャーターがない場合は、実行前に ../qa-report/references/session-charters.md に従って作成します。計画外の操作を実行してはいけません。
• 最初のセッションを開始する前に、レポートテンプレート（プロジェクト内のコピー <qa-docs-path>/templates/report.md、なければ assets/report-template.md）から <qa-docs-path>/reports/<YYYY-MM-DD>-<scope>.md を作成し、マトリックスのすべての行を Pending にします。このディスク上のレポートが再開時の信頼できる情報源です。セッションごと、修正ごとに更新し、最後にまとめて更新するだけにしてはいけません。
• 完了条件： レポートがディスク上にあり、マトリックス全体が記載され、すべての行が Pending になっていること。 ステップ 3 — ペルソナごとに各ジャーニーをたどる
• references/session-protocol.md（入る→操作する→検証する→記録するループと証拠基準）とreferences/persona-fidelity.md（公開インターフェースのガードレールと、行き詰まりも発見事項とする考え方）を読みます。
• 各チャーターについて、マトリックスの順に、ペルソナ（デバイス、ネットワーク、ロケール）になりきり、実際のエントリーポイントから入り、各ステップを証拠基準に照らして検証しながら、ジャーニーを動詞ごとに真の終了状態までたどります。
• 全工程を通して細かな不便を探します。機能チェックでは失敗しない、ペルソナが感じる摩擦を見つけ、深刻なものは発見事項にします。
• 人間だけが完了できる工程（実際の支払い、外部へのメール／SMS送信、実際の OAuth）は、正確な手順を添えてBlocked (needs human verify)と記録します。決して偽装しません。
• **完了条件：**すべてのチャーターをたどって判定を記録し、チェックポイントと相違点の証拠を取得し、報告書の「Session Debriefs」セクションに振り返りを記載し、マトリックスの行を更新していること。

ステップ 4 — 各ツアーとエッジケースのプローブを実行する

• references/tours.md（10 種類のツアーカタログと、サーフェスとツアーの対応マトリックス）とreferences/edge-cases.md（技術に詳しくないユーザーのエッジケース）を読みます。
• 各チャーターのサーフェスに対して、そのペルソナとして、定められた範囲内で単一のツアーを実行し、各操作で「このツアーのテーマにとって重要か？」と問いかけます。
• 変更された契約とリスクに対応する、互いに異なるエッジケースを選びます。最低件数はありません。試行して問題がなかったことも証拠になります。
• **完了条件：**すべてのチャーターでツアーを実行し、選択したエッジケースを試行して記録していること。

ステップ 5 — エクスペリエンスの観点で確認する

• 6 つの観点と、それぞれのデフォルトの深刻度が記載されたreferences/lenses.mdを読みます。
• ユーザビリティ／フルレビューが依頼されている場合、または未解決のエクスペリエンスリスクがある場合は、影響を受けるジャーニーに関連する観点を適用します。最初にたどった際の所見を再利用し、不足している証拠だけを再確認します。
• **完了条件：**該当するエクスペリエンスリスクに証拠があること。または、対象範囲にこの任意の確認が不要であること。

ステップ 6 — 発見事項をレジストリに登録する

• ID、重複排除、影響度の評価基準を定める../qa-report/references/bug-registry.mdを読みます。
• まず重複を排除します。bugs/と、影響を受けるシナリオのbug_idsを検索します。再発見された場合は## Re-foundを追記し、再発した場合は## Regressedを付けて再オープンします。真に新しい症状に限り、新しいBUG-<YYYYMMDD>-<slug> IDを発行します。
• まずユーザーの視点で登録します。影響度、ペルソナ、ジャーニーのステップ、ペルソナのエントリーポイントからの再現手順、証拠のパスを記載してから、影響を受けるシナリオファイルにIDをリンクします。
• **完了条件：**すべての発見事項について重複排除、登録、該当行へのリンクが完了していること。

ステップ 7 — 修正ループ（ガバナーに従う）

• ガバナー、修正ごとの回帰テストのルール、人間の判断が必要な事項を定めるreferences/fix-loop.mdを読みます。
• 編集前に、各修正をガバナーに照らして判断します。ガバナーのすべての制約を満たすものだけを自動修正し、各自動修正には、それを所有するテストスイート／プローブでの証拠を用意します（未カバーの不変条件がある場合に限り回帰テストを追加します）。影響を受けるジャーニーを再度たどり、障害が波及し得る場合は隣接するジャーニーも再確認します。それ以外は、選択肢と推奨案を添えて報告書のDecisions for a Humanに記載します。
• **完了条件：**すべての発見事項が修正・再テスト済み、または推奨案とともにエスカレーション済みであり、修正が中途半端な状態で残っていないこと。 ステップ 8 — ラウンドを終了する
• references/status-and-reporting.md のラウンド終了チェックリストを読み直し、マトリクスの判定を ../qa-report/references/state-schema.md に従ってトラッカーの列挙値に対応付けます。
• 観測された所見、カバレッジ、制限事項を含めて、依頼された QA 範囲を終了します。修正後は、影響を受けるチェックと、その作業でプロジェクトが必須としているチェックを実行し、有効なエビデンスを再利用します。依頼に PR の提出やリリース準備状況の確認も含まれる場合は、該当するデリバリーゲートと現在の HEAD の CI を記録します。必須のエビデンスが欠落または失敗している場合、正直な QA レポートは妨げられませんが、準備完了との判定はできません。
• 完了条件： マトリクスの行に Pending が残っておらず、シナリオファイルの判定とバグのステータスが最新で、各セッションの振り返りがレポートに記載されており、最終ステータスに QA の結果、影響度別の合計、検証したビルドから得たエビデンスが記載されていること。PR やリリースの準備状況は、その判断が依頼範囲に含まれる場合に限り記載します。

関連スキル

• qa-report — このスキルが実行する内容を計画し、ツリーのスキーマ（トラッカー、バグレジストリ、チャーター、ペルソナ、ジャーニー）を管理します。ここに記録した結果は、次のサイクルの計画に活用されます。
• agent-output-audit — CI ゲート、AI テストの衛生チェック、タスクステータスの照合、フレークテストのトリアージを管理します。セッション中にこれらに関わる所見が見つかった場合は、その所見を記録して該当するゲートを明記します。セッションの途中で作業対象を切り替えることはありません。
• agent-browser — ステップ 3〜5 で使用するブラウザードライバーです。コマンドの仕様は references/session-protocol.md にあります。

エラー処理

• 開発サーバーまたはブラウザーツールを利用できない場合： ブラウザーを使う手順を、正確な不足要件とともに Blocked (needs human verify) とし、ペルソナに沿って実行できる CLI／HTTP のジャーニーは続行します。
• フローが停止した場合： セッションを終了して記録し、クリーンなセッションで一度だけ再試行した後、ブロックとしてマークします。停止は記録すべき所見であり、無理に先へ進めるものではありません（references/persona-fidelity.md）。
• 認証情報またはテストデータが不足している場合： 該当セッションを正確な前提条件とともにブロックとしてマークし、残りは続行します。
• マトリクスが作業時間内に収まらない場合： リスクに基づいて絞り込みます（まず Blocks-Completion の候補、次に Data-Loss、次に Trust-Damage）。対象外にした行は理由とともに Skipped とし、最終ステータスで開示します。カバレッジが縮小した場合は明確に示します。