Communitygithub.com

DeanMcCoppin/browser-qa

デプロイ後のUI検証を実際のブラウザで実行:コンソール・ネットワークエラー、Core Web Vitalsのスモークチェック、テストアカウントを使用したフォーム・認証フロー、375/768/1440pxのスクリーンショットとベースライン比較、axeによるアクセシビリティチェックを実施し、「SHIP / SHIP WITH FIXES / DO NOT SHIP」の判定を出力します。ステージング環境やプレビューURLへのデプロイ後、フロントエンドの変更をリリースする前、フロントエンドPRのレビュー時、または公開ページのレスポンシブレイアウトやアクセシビリティを確認する際に使用します。

browser-qa とは?

このスキルは、実際のブラウザ環境(Claude in Chrome、Playwright、Puppeteerなど)を使用して、デプロイ後のウェブページに対して包括的なUI検証を自動実行します。開発者が手動で行うべきQA作業を、スモークテスト、インタラクションテスト、ビジュアルリグレッションテスト、アクセシビリティチェックの4フェーズに分割し、体系化しています。特に、本番環境に対する破壊的操作をデフォルトで禁止する安全設計、Core Web Vitals(LCP < 2.5s、CLS < 0.1、INP < 200ms)の測定、axe-coreによるWCAG 2.2 AA違反の検出、3つのブレークポイント(375px/768px/1440px)でのビジュアル回帰テストなど、実践的なテスト項目をカバーしています。最終的に「SHIP / SHIP WITH FIXES / DO NOT SHIP」の明確な判定を出力するため、CI/CDパイプラインやPRレビューのゲートとして活用できます。対応プラットフォームは、Claude in ChromeのMCP、Playwright MCPサーバー、またはシェルから実行するPlaywrightスクリプトです。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/DeanMcCoppin/Skills/tree/main/plugins/code-audit/skills/browser-qa

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Browser QA — 自動ビジュアルテスト & インタラクション

使用するタイミング

  • 機能をステージング/プレビュー環境にデプロイした後
  • 複数ページにわたるUIの動作を確認する必要がある場合
  • 出荷前にレイアウト、フォーム、インタラクションが実際に動作することを確認したい場合
  • フロントエンドコードに触れるPRをレビューするとき
  • アクセシビリティ監査とレスポンシブテスティング

仕組み

ブラウザ自動化MCP(Claude in Chrome、Playwright、またはPuppeteer)を使用して、実際のユーザーのようにライブページと対話します。

安全性第一 — ブラスト半径(デフォルトは読み取り専用で実行)

Browser QAは実際の認証と実際のユーザージャーニーを駆動するため、ブラスト半径を明示的に扱ってください。 デフォルトは読み取り専用:本番URLに対して変更を伴うジャーニー(チェックアウト、支払い、削除、一括更新)を決して実行しないでください。明示的なオプトインおよびステージング/プレビューURLが必要です。シードされたテスト認証情報を使用し、実際の本番ログインは決して使用しないでください。スクリーンショットを保存する前に、認証情報/トークン/PIIを秘匿化してください。

フェーズ1: スモークテスト

1. 対象URLに移動
2. コンソールエラーを確認(ノイズを除外:アナリティクス、サードパーティ)
3. ネットワークリクエストに4xx/5xxがないことを確認
4. デスクトップ + モバイルビューポートでファーストビューをスクリーンショット
5. Core Web Vitalsをチェック:LCP < 2.5s、CLS < 0.1、INP < 200ms
   (INPは2024年3月にFIDから置き換えられました。しきい値はweb.dev参照)

フェーズ2: インタラクションテスト

1. すべてのナビゲーションリンクをクリック — デッドリンクがないことを確認
2. 有効なデータでフォームを送信 — 成功状態を確認
3. 無効なデータでフォームを送信 — エラー状態を確認
4. 認証フローをテスト:ログイン → 保護ページ → ログアウト(テスト認証情報のみ、本番は不可)
5. 重要なユーザージャーニーをテスト(チェックアウト、オンボーディング、検索)
   — デフォルトは読み取り専用。変更を伴うジャーニーは明示的なオプトインがある場合のみ
     ステージング環境に対して実行(上記「安全性第一」を参照)

フェーズ3: ビジュアルリグレッションテスト

1. 主要ページを3つのブレークポイント(375px、768px、1440px)でスクリーンショット
2. コミットされたベースラインスクリーンショットと比較
   — ベースラインがない場合はINCONCLUSIVEと報告。決してサイレントPASSにしない
3. 5pxを超えるレイアウトシフト、欠落要素、オーバーフローをフラグ
4. 該当する場合はダークモードをチェック

フェーズ4: アクセシビリティ

1. 各ページでaxe-coreまたは同等のツールを実行
2. WCAG 2.2 AA違反(コントラスト、ラベル、フォーカス順序)をフラグ
3. キーボードナビゲーションがエンドツーエンドで機能することを確認
4. スクリーンリーダーのランドマークをチェック

注:axe-coreは自動的にWCAGの約30~40%をカバーします。クリーンな実行は必須ですが、十分ではありません。キーボードナビゲーション、フォーカス順序、スクリーンリーダーでの確認は手動チェックが依然として必要です。自動化パスのみで「アクセシブル」と報告しないでください。

出力形式

## QAレポート — [URL] — [タイムスタンプ]

### スモークテスト
- コンソールエラー:重大0件、警告2件(アナリティクスノイズ)
- ネットワーク:すべて200/304、失敗なし
- Core Web Vitals:LCP 1.2s ✓、CLS 0.02 ✓、INP 89ms ✓

### インタラクション
- [✓] ナビリンク:12/12動作
- [✗] お問い合わせフォーム:無効なメールアドレスのエラー状態が欠落
- [✓] 認証フロー:ログイン/ログアウト動作

### ビジュアル
- [✗] ヒーローセクションが375pxビューポートではみ出している
- [✓] ダークモード:全ページ一貫

### アクセシビリティ
- AA違反2件:ヒーロー画像に代替テキストがない、フッターリンクのコントラストが低い

### 判定:SHIP WITH FIXES(2件の課題、0件のブロッカー)
# 判定 ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP。ビジュアルベースラインがない場合はINCONCLUSIVEを使用

統合

セッションに使用可能なブラウザツールで動作します:Claude in Chrome(mcp__claude-in-chrome__*)、Playwright MCPサーバー、またはシェルから実行するプレーンなPlaywrightスクリプト。どれも利用できない場合は、その旨を伝え、結果を推測する代わりにPlaywrightスクリプトを提案します。

繰り返し可能なチェックについては、結果をe2e-testingでテストに変換します。アクセシビリティの詳細については、accessibilityを参照してください。

関連スキル