--- name: sdd-qa description: 要件・設計・タスクと実装を照合し、テストと実行時の証拠で完成度を検証する。「仕様どおりか確認して」「QAして」「テストと完成度を見て」と依頼されたときに使う。未知の使いづらさを探す探索的な体験確認はsdd-dogfoodingで扱う。 --- # SDD品質確認 要件ごとに、実装と動作の証拠を確かめます。日本語で結果を説明し、ユーザーが別の言語を指定した場合はそれに従います。QAだけの依頼ではコードや仕様を修正せず、レポートと証拠を保存します。 ## 1. 検証する範囲を決める 要件・設計・タスク、対象コードの版、対象URLや起動方法、実行環境を確認します。指定が全体なら差分だけに絞らず、範囲内の要件と受け入れ条件をすべて列挙します。必須条件、任意の作業、対象外を混同しません。 画面、利用者の権限、データの状態、端末やブラウザーなど、仕様上必要な組み合わせを整理します。設定済みのアプリ、ブラウザー、アカウント、サービスを使い回します。ローカルで起動が必要な場合は、起動手順と付随処理を読み、影響を確認してから実行します。共有サービスの再起動、アプリの依存関係の変更、データの初期化はQAだけの依頼では行いません。 ### ブラウザー操作の準備 Webアプリでは、接続済みのPlaywright MCPやCLI、既存のブラウザーセッションを調べます。利用できる接続は使い回します。Playwrightがなければ、Node.js・npm・npxを確認し、利用者専用のツールフォルダーで次を実行します。検証用ツールの準備はQAに含め、アプリの`package.json`やロックファイルは変更しません。 ```text npx --yes --package @playwright/cli@0.1.22 playwright-cli --help npx --yes --package @playwright/cli@0.1.22 playwright-cli list npx --yes --package @playwright/cli@0.1.22 playwright-cli install-browser chromium ``` ブラウザーが不足する場合だけ`install-browser`を実行します。使用中のCLIと同じ版のブラウザーを使います。新規導入や接続変更があれば、チームの`setup`のPlaywright手順と確認用ページを使えます。単独で使う場合も、ツール用フォルダーに外部送信しない確認用ページを作り、`127.0.0.1`だけで配信します。CLIでブロックされる`file://`は使いません。実際に開いてボタンを押し、表示の変化とスクリーンショットを確かめます。操作方法はCLIの`--help`で確認します。既存の接続を使う場合は、対象アプリでのスナップショット取得から進めます。生成画像の内容まで確認し、ヘルプ表示だけで準備完了としません。 `list`でセッションを選び、既存セッションに`open`を実行して再起動させないようにします。操作前に最新のスナップショットを取得し、画面が変われば参照を取り直します。今回作ったタブや専用セッションだけを閉じ、`close-all`・`kill-all`は使いません。証拠は`output/playwright/`など既存の保存規則に合わせます。 Node.jsやOSの必要条件は[公式案内](https://playwright.dev/docs/intro#system-requirements)を確認します。権限・ネットワーク制限で準備できなければ、その確認を`BLOCKED`として残し、独立した確認を続けます。シェルがない場合は使えるブラウザー機能を使い、ローカルへの導入とは区別します。iOSなどのネイティブアプリでは既存のXcode・シミュレーター等を使い、Playwrightのモバイル表示だけで実機相当の確認を済ませません。CLIの詳細は[Microsoftの公式案内](https://github.com/microsoft/playwright-cli)を参照します。 次の表で各条件の確認先と証拠を管理します。 | 要件・受け入れ条件 | 期待する動作 | 実装・テストの確認先 | 実際の結果・証拠 | 判定 | 未確認の理由 | | --- | --- | --- | --- | --- | --- | | 各条件を1行ずつ記載 | 操作と結果 | ファイルやテスト名 | コマンド、画面、保存結果など | 下記の判定 | 必要な場合に記載 | ## 2. 実装とテストを追う 要件を、入口、処理、データや外部サービス、出力、失敗時の処理まで追います。チェック済みのタスク、関数名、コメント、生成ファイルの存在だけでは実装の証拠にしません。 既存テストが何を確かめているかを読みます。通常時に加え、仕様に関係する入力の限界、権限、状態の変化、同時操作、取り消し、互換性、後片付けを確認します。すべてのプロジェクトに同じ検査を強制せず、必要な条件が抜けていないかを判断します。 安全に実行できる関連テストや静的検査を実行します。コマンド、環境、使用データ、終了結果、ログや成果物を記録します。以前の実行結果、スキップしたテスト、不安定なテスト、代役の依存先だけを使うテストは、その制約を示します。合格させるための仕様変更、期待値の緩和、失敗の隠蔽は行いません。 ## 3. 実際の利用経路を確かめる 仕様で求める操作を、実際の画面やAPIで行います。画面表示だけでなく、応答内容、再取得や再読み込み後の状態、必要な保存結果まで確認します。ビルド成功やヘルスチェックの応答だけで、認証付きの操作や外部サービス接続を確認済みにしません。 - 既存の認証済みセッションを優先します。通常のログインは利用できますが、認証回避や未承認のアカウント作成は行いません。ログインや権限が足りなければ、止まっている確認と必要な操作をユーザーに伝えます。パスワードやトークンをチャットへ貼らせません。 - 保存、投稿、アップロード、削除、支払いなどが必要な確認では、すでに与えられた権限を確かめます。権限がなければ、対象環境と変更内容を示し、その操作か既存の確認用データを求めます。自動保存か分からない入力も勝手に行いません。 - 操作部品がDOMやアクセシビリティ情報に出ない場合は、画面を見て、利用できるツールの視覚操作やネイティブ操作で確認します。ツールが対応しない操作は具体的にユーザーへ依頼し、未実行として残します。 - 確認が止まっている間は独立した項目を進めます。必要な権限や環境がそろったら、同じアプリとセッションで再開します。 テスト用の代役は、明示された境界だけの証拠です。実サービスが使えないことを理由に仮の成功応答を採用したり、必要な確認を対象外へ移したりしません。出力ファイルが要件なら、存在やサイズに加えて内容と形式を確かめます。 ## 4. 条件ごとに判定する | 判定 | 意味 | | --- | --- | | `PASS` | その条件を、現在の実装と必要な実行証拠で満たした | | `FAIL` | 条件に反する動作、欠けた実装、失敗する検証を確認した | | `BLOCKED` | 特定の権限、判断、依存先などが足りず確認を進められない | | `NOT VERIFIED` | 未実行、古い証拠、証拠不足などによりまだ判断できない | 仕様に含まれない項目だけを、理由付きで対象外にできます。必須条件に`BLOCKED`や`NOT VERIFIED`があれば、全体を合格とは報告しません。確認できないことと、観察した製品の不具合を分けます。 最後に対応表を見直し、未記載の要件や抜けた操作がないか確認します。不具合は、影響、期待と実際の違い、再現手順、証拠、該当箇所、修正方針の順にまとめます。原因が仕様、実装、テスト、環境のどこにあるかも示します。 ## 修正と再確認 修正まで依頼されている場合は、まず元の不具合と証拠を残します。その後、実装や仕様変更を別の工程として行い、変更した版で影響する項目を再確認します。修正依頼がない場合は、調査結果と次の作業を返します。QAの合格と、マージや本番公開の完了は分けて報告します。