qa-systematic

システマティック QA テスト

モード

フル（デフォルト）

ページごとのシステマティックなテスト、8 カテゴリーの健全性スコア、問題の完全な記録を行います。

クイック

重要な経路のみを対象とした 30 秒のスモークテストです。ログイン、メインナビゲーション、主要なアクションを確認します。

リグレッション

現在の状態を保存済みのベースラインと比較し、新規および解消済みの問題を報告します。

ブラウザー自動化の検出

利用可能な自動化手段を、次の優先順位で検出します。

1. Playwright MCP サーバー — 現在のツール一覧で Playwright ツールが利用可能か確認します
2. agent-browser スキル — agent-browser スキルが読み込まれているか確認します
3. 直接利用可能な CLI ツール — PATH 上に playwright、puppeteer、または cypress バイナリがあるか確認します
4. 手動での代替手段 — ユーザーに操作と所見の報告を依頼します

利用可能な手段のうち、最も優先順位の高いものを使用します。レポートの冒頭で使用する手段を明記します。

ワークフロー

フェーズ 1：初期化

1. ユーザーのプロンプトからモードを検出します。指定がない場合は、デフォルトでフルにします。
2. アプリケーションの URL を検出します。
   • フレームワークのポート規則（例：Next.js → 3000、Vite → 5173、Django → 8000）について、references/project-detection.md を確認します。
   • 検出できない場合は、ユーザーに確認します。
3. 利用可能なブラウザー自動化手段を検出します（上記の優先順位リストを参照）。
4. リグレッションモードの場合：.qa-reports/ から以前のベースラインを読み込みます。

フェーズ 2：認証（必要な場合）

1. ルート URL に移動し、ログイン画面が表示されるか確認します。
2. 認証情報が提供されている場合：認証を行い、セッションを保存します。
3. 提供されていない場合：ユーザーにテスト用の認証情報を尋ねるか、認証が必要なページをスキップし、レポートにその制約を記載します。

フェーズ 3：全体把握

1. ルート URL に移動します。
2. 主要なナビゲーション構造を確認し、最上位のナビゲーションリンクをすべて収集します。
3. 各ページを分類します：静的、フォーム、リスト、詳細、ダッシュボード。
4. ページカテゴリーごとにテスト計画を作成し、実施順を決めます（不具合の発生密度が最も高いフォームとダッシュボードを優先します）。

フェーズ 4：調査（フルモード）

各ページで、以下のページごとのチェックリストを実行します。クイックモードでは、(Q) が付いた項目のみ実行します。

ビジュアルチェック

• (Q) レイアウトが正しく表示される — 重なりやはみ出しがない
• 画像が読み込まれる — 壊れた <img> タグがない
• タイポグラフィが一貫している — フォントのフォールバックが目に見えて発生していない
• レスポンシブ対応：デスクトップ（1280px）とモバイル（375px）の幅で確認する

インタラクティブ要素

• (Q) すべてのボタンとリンクがクリックに反応し、適切に動作する
• 想定される箇所にホバー状態がある
• キーボード操作時にフォーカスインジケーターが表示される
• 無効状態が視覚的に区別できる

フォーム

• (Q) 必須項目の検証が、空のまま送信したときに実行される
• 無効な入力に対してエラーメッセージが表示される
• 有効な送信に対して成功フィードバックがある
• フォームの再送信が適切に処理される — ダブルクリックしても重複送信されない

ナビゲーション

• (Q) すべてのナビゲーションリンクが正しく遷移する — 404 がない
• 戻るボタンが期待どおりに動作する
• ディープリンクが機能する — URL に直接アクセスすると正しいページが表示される
• パンくずリストが正確である（ある場合）

状態管理

• 非同期処理中に読み込み状態が表示される
• 空の状態が適切に処理される — データがないときにページが真っ白にならない
• エラー状態から復帰できる — 再試行または戻るための選択肢がある
• ページ移動後もデータが保持される — 戻る／進む操作でフォームデータが失われない

コンソール

• (Q) コンソールに JavaScript エラーがない
• 失敗したネットワークリクエストがない（4xx/5xx）
• 混在コンテンツの警告がない
• 重要な処理経路に非推奨の警告がない

レスポンシブ対応

• モバイルレイアウトが使用可能である — 375px で横スクロールが発生しない
• タッチターゲットが 44px 以上である
• 拡大しなくてもテキストが読みやすい（本文が 16px 以上）

フェーズ 5：記録

見つかった各問題を、references/issue-taxonomy.md を使用して分類します。

• 重大度：critical（使用を妨げる）、major（使用感を損なう）、minor（見た目や仕上げの問題）
• カテゴリー：機能、ビジュアル、アクセシビリティ、パフォーマンス、コンテンツ、ナビゲーション、セキュリティ、コンソール
• 証拠：スクリーンショットの説明または再現手順

一意の ID を割り当てます：QA-001、QA-002 など。

以下の重みを使用し、references/report-template.md の詳細に従って健全性スコアを算出します。

フェーズ 6：終了処理

1. references/report-template.md に従って構造化レポートを生成します。
2. .qa-reports/<YYYY-MM-DD>-<mode>.json に保存します。
3. full モードの場合：今後の回帰比較に備えてベースラインを保存します。
4. 概要を提示します：ヘルススコア、重大・大・小の件数、優先度の高い修正項目トップ 3。

ヘルススコア

8 つのカテゴリの加重平均で、0〜100 の範囲で採点します。

カテゴリ	重み
コンソールエラー	15%
リンク切れ	10%
機能性	20%
UX／ユーザビリティ	15%
アクセシビリティ	15%
ビジュアル	10%
パフォーマンス	10%
コンテンツ	5%

カテゴリごとの採点：100 点から始め、問題の重大度に応じて減点します。

• 致命的：-30
• 大：-15
• 小：-5

下限は 0 点です。最終的なヘルススコアは、カテゴリスコアの加重合計です。

クイックモードの動作

フェーズ 4 のチェックリストで (Q) とマークされた項目のみを実行します。ヘルススコアの算出は省略し、重要なクリティカルパスごとに合格／不合格を報告します。目標完了時間：実際のテスト時間で 30 秒です。

回帰モードの動作

1. .qa-reports/ から最新のベースラインを読み込みます。
2. full モードを実行します。
3. ID と説明の類似度で問題を差分比較します。
4. 新規の問題、解決済みの問題、継続中の問題を報告します。
5. 更新したベースラインを保存します。