qa-test-planner

QA テストプランナー

QA オートメーションエンジニアがテスト計画を作成し、手動テストケースを生成し、自動化された Playwright テストを構築し、回帰テストスイートを作成し、ブラウザー自動化で UI を検証し、効果的にバグを記録するための包括的なスキルです。

有効化： このスキルは、名前を明示的に指定した場合（例：/qa-test-planner、qa-test-planner、または use the skill qa-test-planner）にのみ起動します。

クイックスタート

テスト計画を作成する：

"Create a test plan for the user authentication feature using the test-plan.md template"

テストケースを生成する：

"Generate manual test cases for the checkout flow using the test-case.md template"

自動化された Playwright テストを作成する：

"Create Playwright automated tests for the login flow using the playwright-test.md template"

ブラウザーで UI を検証する：

"Navigate to the login page and validate all form elements are visible using Playwright MCP"

回帰テストスイートを構築する：

"Build a regression test suite for the payment module using test-case.md templates grouped by priority"

バグレポートを作成する：

"Create a bug report for the form validation issue using the bug-report.md template"

クイックリファレンス

このスキルを使う場面

次のような場合に、このスキルを使います。

• テスト計画やテスト戦略を作成またはレビューする
• 要件やユーザーストーリーからテストケースを生成する
• 再現手順が明確なバグレポートを作成する
• リスクベースで選定した回帰テストスイートを構築する
• ベストプラクティスに沿ってPlaywright による自動化を実装する
• テスト実行と結果を記録する
• 探索的テストセッションを実施する
• ブラウザー自動化でUI 要素を検証する

前提条件

仕組み

Your Request
    │
    ▼
┌─────────────────────────────────────────────────────┐
│ 1. ANALYZE                                        │
│    • Parse feature/requirement                      │
│    • Identify test types needed (manual/automated)  │
│    • Determine scope and priorities                 │
├─────────────────────────────────────────────────────┤
│ 2. SELECT TEMPLATE                                │
│    • Choose appropriate template from assets/        │
│    • Review template structure and sections         │
│    • Identify placeholders to fill                 │
├─────────────────────────────────────────────────────┤
│ 3. CUSTOMIZE                                      │
│    • Fill in placeholders with project details      │
│    • Add specific test steps and scenarios         │
│    • Apply Playwright best practices               │
├─────────────────────────────────────────────────────┤
│ 4. EXECUTE (with Playwright MCP)                 │
│    • Navigate and interact with browser             │
│    • Capture screenshots and evidence               │
│    • Validate UI elements and behavior              │
├─────────────────────────────────────────────────────┤
│ 5. VALIDATE                                       │
│    • Check completeness                             │
│    • Verify traceability                            │
│    • Ensure actionable steps                        │
└─────────────────────────────────────────────────────┘
    │
    ▼
QA Deliverable Ready

ワークフロー

1) テスト計画を作成する

1. 出発点として templates/test-plan.md を使用します
2. テストの目的、対象範囲、前提条件、制約を特定します
3. テストレベルとテストタイプ（機能、UI、パフォーマンスなど）を定義します
4. 環境、テストデータ、ツール、設定の要件を指定します
5. 開始／終了基準、成果物、報告頻度を定義します
6. リスクマトリックスと緩和策を追加します
7. それに応じてテストに優先順位を付けます（リスクベースドテスト）

テンプレート： templates/test-plan.md

2) テストケースを生成する

1. 個々のテストケースには templates/test-case.md を使用します
2. 要件をテスト条件（何をテストするか）に変換します
3. テスト設計技法を選びます。
   • 入力には同値分割と境界値分析
   • ルールの組み合わせには決定表
   • ライフサイクル／フローには状態遷移
   • エンドツーエンドの操作にはユースケース／シナリオテスト
4. 独立性があり、曖昧さがなく、追跡可能なテストケースを作成します
5. 観察および測定可能な期待結果を追加します
6. リスクベースの回帰テストに役立つ優先度とリスクのタグを追加します
7. 安定性と価値の基準を使って自動化候補を指定します

テンプレート：

• templates/test-case.md - 個別のテストケース

3) 自動テストスクリプトを実装する（Playwright）

1. テンプレートとして templates/playwright-test.md を使用します
2. テストの読みやすさを保ち、テストケースに沿わせます
3. 壊れやすいセレクターより、安定したロケーター（例：getByTestId）を優先します
4. 恣意的な待機時間は避け、Playwright の自動待機と明示的なアサーションを使用します
5. テストを独立させます（前提条件を明示的に設定します）
6. テストタイトルにタグ（例：@smoke、@regression）を付けて、テストスイートの実行に活用します
7. デバッグ時のトリアージ用に、成果物（スクリーンショット／動画／トレース）を取得します

テンプレート： templates/playwright-test.md

4) 回帰テストスイートを構築・維持する

1. templates/regression-suite.md を使用してスイートを定義します
2. スイートの階層を定義します：スモーク（重要なパス）、サニティ（ビルド検証）、回帰（広範囲）、フル（リリース）
3. リスク、頻度、重要度、欠陥履歴を基にテストを選択します
4. テストに一貫性のあるタグを付け、選択ルールを文書化します
5. スイートを定期的に見直します：古くなったカバレッジを削除し、すり抜けた欠陥に対するカバレッジを追加します

テンプレート： 優先度ごとにまとめた個別の test-case.md テンプレートを使用します

5) バグレポートを作成する

1. templates/bug-report.md を出発点として使用します
2. 確実に再現できるようにし、手順を最小限に絞ります
3. ばらつき（頻度）と影響範囲を記録します
4. 環境の詳細（ビルド／アプリのバージョン、OS、ブラウザー／デバイス、アカウント／ロール）を記録します
5. 期待される動作と実際の動作を説明します
6. 影響を含め、重大度と優先度を一貫した基準で設定します
7. 証拠（スクリーンショット、コンソールログ、ネットワークトレース、Playwright のトレース）を添付します
8. ライフサイクルを追跡します：トリアージメモ、担当者、修正バージョン、検証手順

テンプレート： templates/bug-report.md

セキュリティガイドライン

認証情報の取り扱い

テストケースやコードに実際の認証情報を埋め込まないでください。 代わりにプレースホルダーを使用します：

テストデータのベストプラクティス：

• API または管理パネルを介してプロビジョニングされたテストアカウントを使用します
• 認証情報を環境変数に保存します
• Faker.js などを使用してテストデータを生成します
• 実際の認証情報をバージョン管理にコミットしないでください

URL ナビゲーションの安全性

Playwright MCP を使用して外部または信頼できない URL を検証する場合：

1. ナビゲーションする前に、URL が信頼できるドメインのものか確認します
2. 信頼できないソースからの任意の JavaScript の実行は避けます
3. サードパーティーアプリケーションのテストでは、サンドボックス環境を使用します
4. 検証せずに、信頼できないユーザー入力で提供された URL に移動しないでください

入力のサニタイズ

すべてのユーザー入力は、次の要件を満たす必要があります：

• 期待される形式であることを検証する
• 生成コードで使用する場合はエスケープする
• eval() やシェル実行に直接渡さない

アンチパターン

検証チェックリスト

テスト計画：

• スコープが明確に定義されている（対象／対象外）
• 開始／終了基準が指定されている
• リスクが軽減策とともに特定されている
• スケジュールが現実的である

テストケース：

• 各ステップに期待結果がある
• 前提条件が文書化されている
• テストデータでプレースホルダーを使用している（認証情報をハードコードしていない）
• 優先度が割り当てられている

自動テスト：

• ロールベースのロケーターを使用している
• Web ファーストのアサーションを実装している
• ページオブジェクトモデルを適用している
• 明確にするために test.step() でグループ化している
• エラーハンドリングとスクリーンショットを含めている
• 認証情報を環境変数から読み込んでいる

バグレポート：

• 再現可能な手順がある
• 環境が文書化されている
• スクリーンショット／証拠が添付されている
• 重要度／優先度が設定されている

テンプレート

利用可能なテンプレート

テンプレートの使用方法

すべてのテンプレートは templates/ にあります。使用するには、次の手順に従ってください。

1. テンプレートをコピーして、プロジェクトディレクトリに配置します
2. プレースホルダーに入力します（[brackets] または ${VARIABLE} で示されています）
3. セクションをカスタマイズして、具体的なニーズに合わせます
4. 必要に応じてセクションを削除または追加します
5. 完成したドキュメントを保存し、バージョン管理します

参考資料

• references/test_case_templates.md - すべてのテストタイプに対応する標準フォーマット
• references/bug_report_templates.md - ドキュメントのテンプレート
• references/regression_testing.md - テストスイートの構築と実行
• references/playwright_automation.md - ブラウザーの自動化とテスト生成

例

"Create a test case for user login with valid credentials using the test-case.md template"

"Create a bug report for a login form validation issue using the bug-report.md template"

"Create Playwright tests for the login flow using the playwright-test.md template"

ベストプラクティス（上記のアンチパターンを避ける）

テストケースの作成

• 具体的かつ明確に記述し、各手順の期待結果を含めます
• 1 ケースにつき 1 つの項目をテストし、すべての前提条件とテストデータを記録します
• エッジケースと境界値を含め、一貫した命名を使用します

バグ報告

• 最小限で正確な再現手順を記載し、環境の詳細を明記します
• スクリーンショットや動画を含め、ユーザーとビジネスへの影響を説明します
• 重大度と優先度を設定し、明確で具体的なタイトルを付けて重複を避けます

回帰テスト

• 繰り返し実行するテストを自動化し、重要なパスを優先します
• スモークテストを頻繁に実行し、テストスイートを定期的に見直して整理します
• 一貫したタグ付けを行い、失敗した回帰テストを決して無視しません

セキュリティ

• 認証情報には環境変数を使用し、シークレットをコミットしないでください
• 移動前に URL を検証し、疑わしいコンテンツを報告します
• ユーザー入力から任意の JavaScript を実行しないでください

品質ゲート（自己チェック）

• テスト計画には、範囲、アプローチ、リスク、環境、開始／終了基準、成果物、メトリクスが含まれています
• テストケースは追跡可能で、独立した単位になっており、決定論的で、明確なオラクルとデータを含んでいます
• 自動化は保守しやすいものです（安定したロケーター、最小限の不安定さ、独立したテスト、明確なアサーション）
• 回帰テストはリスクベースでタグ付けされ、追加／削除の明確なルールに基づいて整理されています
• バグレポートは再現可能で、対応につながる内容になっており、証拠、環境、影響が含まれています

トラブルシューティング

よくある合理化

テストの品質を損なう、よくある近道や「これで十分」という言い訳と、それぞれの実態を示します。

「テストはバグの存在を示すものであり、不在を示すものではない。」- エドガー・ダイクストラ

「品質とは行為ではなく、習慣である。」- アリストテレス

検証

このスキルのワークフローを完了したら、次の項目を確認してください。

• テスト戦略ドキュメントを作成済み — スコープ、アプローチ、リソース、スケジュール、リスクを網羅しています
• テストレベルを定義済み — 単体、統合、E2E、受け入れの各レベルと基準を定めています
• 開始／終了基準を文書化済み — テストの開始と終了の条件を明確に定義しています
• リスクベースの優先順位付けを実施済み — 影響度 × 発生可能性に基づいてテストに優先順位を付けています
• 環境要件を一覧化済み — ハードウェア、ソフトウェア、データ、ネットワークの要件を記載しています
• 欠陥管理プロセスを定義済み — バグの報告、追跡、解決方法を定めています
• ステークホルダーの承認を取得済み — 関連するステークホルダーがテスト計画をレビューし、承認しています