playwright-qa

Playwright による QA

目的

Web アプリケーション向けの自動ビジュアル QA テストです。Playwright を使用してヘッドレスブラウザーを起動し、実際のユーザーのようにアプリを操作して、スクリーンショットの撮影、コンソールやネットワークのエラーの確認、インタラクティブ要素のテスト、レスポンシブレイアウトの検証、ビジュアルバグの特定を行い、可能な場合は自動で修正します。

ルーティング

• 使用する場合：テスト、バグの発見、動作確認、リリース、品質に関する記述があるWebアプリのタスクで使用します。Playwright やビジュアル QA に明示的に言及していない場合も対象です。Web アプリを作成するタスクで、正常に動作することが暗黙に期待されている場合も使用します。
• 使用しない場合：ユニットテスト、API テスト、Web アプリケーション以外のテスト、ネイティブモバイルアプリのテストのみを行うタスクでは使用しません。
• 出力：チェック結果（合格／不合格）、重大度別に分類した問題、スクリーンショット、操作ログを含む QA レポート。
• 成功基準：すべてのチェックに合格するか、問題が明確な説明とともに特定され、可能な場合は自動修正されること。

トリガーの例

該当する例

• React で ToDo アプリを作成し、リリース前にバグを見つけるためにテストする
• ダッシュボードを作成し、正常に動作することを確認する
• ランディングページを作成し、すべてが正しく表示されることを確認する
• この Web アプリを作成し、バグのない状態でリリースする
• React アプリを作成してテストする
• 天気アプリを作成し、問題がないか確認する
• アプリを作成して QA を行う
• フロントエンドを作成してテストする
• アプリは動作しますか？
• Playwright でこの Web アプリをテストする
• localhost:3000 でビジュアル QA を実行する
• サイトにバグがないか確認する
• ブラウザーの自動テストを実行する
• UI が動作することを確認する
• Web アプリのスクリーンショットを撮影してテストする
• プロジェクトのビジュアルバグを見つける
• 実際のユーザーのようにアプリをテストする
• フロントエンドの QA を行う
• Playwright のテストを実行する
• リリース前に正常に動作することを確認する

該当しない例

• Jest でユニットテストを書く
• jest/vitest のテストを実行する
• curl で API エンドポイントをテストする
• k6 で負荷テストを行う
• ネイティブの iOS/Android アプリである
• バックエンドのユニットテストを実行する

パラメーター

名前	型	必須	説明
url	string	いいえ	テスト対象の URL（デフォルトは http://localhost:3000）
server_command	string	いいえ	開発サーバーを起動するコマンド（例："npm run dev"）
checks	string	いいえ	チェック項目をカンマ区切りで指定します：visual_snapshot、console_errors、network_errors、interaction_test、responsive_check、accessibility_check、performance_check

ランタイムプロンプト

Playwright を使用して、Web アプリケーションのビジュアル QA を自動実行しています。

ワークフロー：

1. 依存関係をインストールする（プロジェクトを新たに作成した場合）：

   • プロジェクトに package.json があり、node_modules がない場合は、まず run_command で npm install（または yarn／pnpm install）を実行します。
   • 新規作成したプロジェクトでは、この手順を絶対に省略しないでください。依存関係をインストールしないと、npm run dev は失敗します。

2. 開発サーバーを起動する（まだ起動していない場合）：

   • server_command を指定して qa_run を使用し、自動的に起動するか、
   • 必要に応じて run_command を使用し、手動でサーバーを起動します。

3. QA パイプライン全体を実行する：

   • 対象 URL と有効にするチェック項目を指定して qa_run を呼び出します。
   • これにより、ブラウザーの起動、ページへの移動、コンソールエラーの確認、ネットワークエラーの確認、ビジュアルスナップショットの取得、インタラクティブ要素のテストが自動的に行われます。

4. 結果を確認する：

   • QA レポートで問題がないか確認します。
   • 問題は重大、メジャー、マイナーに分類されます。

5. 問題を修正する（auto_fix が有効な場合）：

   • 重大またはメジャーな問題ごとに、コードを修正します。
   • qa_run を再実行して、修正を検証します。
   • 重大またはメジャーな問題がすべて解決するまで繰り返します。

6. 手動テスト（特定のフローを確認する場合）：

   • qa_navigate を使用して、特定のページに移動します。
   • qa_interact を使用して、ユーザーフローをテストします（ボタンのクリック、フォームへの入力、要素へのホバーなど）。
   • qa_screenshot を使用して、特定の状態をキャプチャします。
   • qa_check を使用して、特定のチェックを実行します。

7. クリーンアップ：

   • 完了したら、必ず qa_cleanup を呼び出します。

主なツール：

• qa_run — 自動パイプライン全体を実行します（最初に使用することを推奨）
• qa_navigate — URL に移動します
• qa_interact — クリック、入力、ホバー、スクロールを行います
• qa_screenshot — 診断情報とともにスクリーンショットを撮影します
• qa_check — 特定のチェックを実行します
• qa_report — 現在の実行レポートを取得します
• qa_cleanup — ブラウザーとサーバーを終了します

ベストプラクティス：

• 最初に qa_run を実行し、包括的な初回チェックを行います
• マイナーな問題より先に、重大な問題を修正します
• 修正を検証するため、修正後に再実行します
• 特定のユーザーフローのテストには qa_interact を使用します
• 重要なインタラクションのポイントでスクリーンショットを撮影します
• デスクトップとモバイルの両方のビューポートを確認します