grill-me-qa

QA の徹底レビュー

QA 自動化計画やテスト戦略のあらゆる側面に踏み込み、すべての判断が確定するまで体系的に検討するガイド付きインタビューです。AI 支援テストツールを活用する QA 自動化エンジニア、SDET、QA リードを対象としています。

有効化： ユーザーがテスト計画、テスト戦略、フレームワークの選定、テストアーキテクチャ、または AI テスト戦略を検証、精査、あるいはストレステストしたい場合に有効化されます。明示的な参照「use the skill grill-me-qa」でも有効化されます。

このスキルを使用する場面

• 新しいテスト自動化プロジェクトやフレームワークを開始する前
• テスト生成、自己修復、分析に AI ツールを導入する際
• テスト戦略を関係者に提示する前
• 既存のテストスイートをリファクタリングまたは移行する際
• ツールやフレームワークのトレードオフ（Playwright vs Selenium vs Cypress vs k6）を評価する際
• テストカバレッジを拡大したり、回帰テストスイートを再編成したりする前
• 不安定なテストによってテストスイートへの信頼が損なわれている場合

起動フレーズ

このスキルは、明示的な依頼と暗黙的な意図の両方で有効化されます。英語とスペイン語の次のフレーズを起動シグナルとして扱ってください。

• "grill my test plan", "audit my QA automation framework", "challenge my QA strategy"
• "challenge my testing decisions", "review my test architecture"
• "should I use Playwright or Cypress?", "how should I structure my tests?"
• "my tests are flaky, help me figure out why"
• "migrate from Selenium to Playwright", "is my test pyramid healthy?"
• "how do I set up quality gates?", "why is my test suite so slow?"
• "revisa mi estrategia de pruebas", "audita mi plan de QA"
• "audita mi framework de automatización", "pon a prueba mi framework de automatización"
• "mis tests son flaky", "revisa mi arquitectura de pruebas"

このスキルを使用しない場面

このスキルは、戦略とアーキテクチャに関する判断を徹底的に検討します。次の用途には適していません。

• 単一のテストを作成またはデバッグする場合 → playwright-e2e-testing、api-testing、または該当するフレームワークスキルを使用してください
• 本番コード（テストコード以外）の一般的なコードレビュー
• 1 件の孤立した失敗テストを修正する場合（これは戦略ではなくデバッグです）

依頼が実務的な内容（「ログインテストを書いて」「このセレクターが失敗するのはなぜ？」など）の場合は、実装スキルに引き継いでください。

対象範囲と除外事項

このスキルは、Web および API のテスト自動化を対象としています。5 つの観点は幅広く適用できますが、ツールの推奨事項（観点 2）と非機能要件（観点 1）は Web／API の状況に合わせて調整されています。

• モバイルネイティブ（Appium / XCUITest / Espresso）、組み込み、またはハードウェアインザループテスト： 観点は適用できますが、フレームワークや NFR の推奨事項はそのまま当てはまらない場合があります。フェーズ 1 でこの点を明示し、Web ツールを推奨するのではなく、観点 2／1.3 の回答を適宜調整してください。
• モバイルテストとコントラクトテストは、独立した対象として意図的に範囲外としています。 これらは別のスキルで扱います。

徹底的な検討の進め方

中核プロトコル

1. 質問は一度に1つだけにします。 複数の質問を同時にしてはいけません。次に進む前に、ユーザーの回答を待ちます。質問を重ねるとユーザーを圧倒し、回答が浅くなります。
2. すべての質問に推奨回答を提示します。 業界のベストプラクティス、ISTQB の原則、プロジェクト固有の状況に基づいて推奨します。推奨を示すことで、ユーザーは具体的な初期案を受け入れるか、異議を唱えることができます。
3. 質問する前に調査します。 コードベース、テストスイート、CI 設定、既存のドキュメントを確認すれば答えられる質問は、ユーザーに尋ねずに調べます。ユーザーの時間を尊重することも、綿密さの一環です。
4. 意思決定のツリーを体系的にたどります。 5つの次元を順番に進めます。次の分岐に移る前に、意思決定間の依存関係を一つずつ解決します。
5. 曖昧な回答には確認を求めます。 ユーザーの回答が不正確な場合は、さらに質問して明確にします。「場合によります」は回答ではありません。具体的な状況を踏まえた決定を促します。
6. 意思決定を記憶します。 セッションを通じて、確定した決定、保留項目、未解決の質問を記録し続けます。この記録は内部で保持します。セッション中に、すでに決定した内容の要約でユーザーの作業を中断してはいけません。決定記録の全容は、最後に TSDR で提示します。

適応型の推奨

Phase 1 で特定したプロフィールに合わせて、推奨する回答を調整します。個人で活動する SDET に適したアドバイスは、企業の QA Lead には適しません。

• SDET（個人）： 実用性と導入の速さを重視し、独自フレームワークより既製ツールを優先します。
• QA Lead： 戦略的かつエンタープライズグレードの視点を持ち、ガバナンス、指標、チームの拡張性を重視します。
• QA Engineer（個人）： 実践的かつチーム志向で、リリースの速さと保守性のバランスを取ります。

セッションの流れ

Phase 1: Context Discovery + Codebase Exploration
  → Capture the user's role, team size, project maturity, greenfield/legacy, constraints
  → What are we grilling? (plan, strategy, framework choice, AI adoption)
  → Explore codebase, test suite, CI config, existing docs
  → Use this context to select the most relevant questions per dimension
  → If no codebase exists yet (pure greenfield), skip exploration and rely on the context
    questions above; note "greenfield — no codebase to explore" in the TSDR.

Phase 2: Systematic Grilling (5 Dimensions, 10-15 questions max)
  → Walk through each dimension, one question at a time
  → Select the 2-3 most critical questions per dimension based on the Phase 1 profile
  → Provide recommended answer, wait for user's decision
  → Resolve dependencies before moving forward
  → Dimension 4 (AI) opens with a gate question — quick-exit if AI is not in use

Phase 3: TSDR Generation
  → Summarize all decisions into a Test Strategy Decision Record (TSDR)
  → Offer Markdown and/or HTML output

質問の上限

セッション全体の質問数は 10～15問 に収めます。15問を超えて質問攻めを続けると、ユーザーを疲弊させ、得られる情報の質も下がります。質問数に含めるのは、5つの次元に関する 掘り下げ質問のみ です。Phase 1 のコンテキスト確認の質問は無料で、上限には含めません。

上限を守るためのルール：

• Phase 1（コンテキストの確認）は無料です。役割、チームの規模、新規開発かレガシーか、制約に関する質問は10～15問の上限に含めません。
• 各次元の主要な質問は2～3問とし、Dimension 4（AI）と Dimension 5 は最大4問までとします（上限は3+3+3+4+4=17問）。Dimension 4 の AI 導入判定で通常は質問数を2問以下に絞れるため、各次元では2問を目安とします。ただし、その次元がプロジェクトにとって高リスクの場合は例外です。
• Dimension 4（AI）の導入判定の質問は上限に含めます（AI の簡易終了時は最大2問）。
• 追加の掘り下げは、質問の追加ではなく取捨選択として扱います。 ある次元で主要な質問をすべて行った場合、別の次元の質問数を減らさない限り、その次元で追加の掘り下げはできません。15問を目標とし、16問になるのは Dimension 4 で主要な質問をすべて行う場合に限ります。
• 網羅性より深さを重視します。鋭い質問を少数行うほうが、一般的な質問を長々と並べるより多くのことを解決できます。

5つの次元

各次元には、具体的な掘り下げポイントを含む意思決定ツリーがあります。質問項目の全容については、references/qa-decision-tree.md を参照してください。

Dimension 1：テスト戦略とカバレッジ

• このプロジェクトに適したテストピラミッドの形は何ですか？
• リスクに基づいて、カバレッジの優先順位をどう決めますか？
• 自動テストと探索的テストの境界はどこですか？
• どのような非機能テストが必要ですか（パフォーマンス、セキュリティ、アクセシビリティ）？

Dimension 2：フレームワークとツール

• 他の選択肢ではなく、このフレームワークを選ぶ理由は何ですか？（Playwright / Selenium / Cypress / k6 / その他）
• 使用する言語と、その理由は何ですか？（TypeScript / Java / Python / その他）
• どの設計パターンを採用しますか？（ページオブジェクトモデル / スクリーンプレイ / Fluent API / ハイブリッド）
• どのレポート作成ツールと可観測性ツールを使いますか？

ディメンション 3：テストアーキテクチャ

• テストは互いにどのように分離されていますか？
• テストデータの方針は何ですか？（シード、クリーンアップ、ファクトリー、フィクスチャ）
• 環境はどのように管理されていますか？（ローカル、ステージング、CI）
• 並列化の方針は何ですか？
• リトライと不安定なテストへの対応方針は何ですか？

ディメンション 4：AI 統合

• テストのワークフローのどこで AI を利用していますか？（生成、修復、分析、ビジュアル、トリアージ）
• AI が生成したテストの正確性は、どのように検証していますか？
• 人間が介在する境界はどこですか？
• ハルシネーションと非決定的な出力をどのように軽減していますか？
• AI 支援テストのコスト／トークン予算はいくらですか？
• どの AI ツールを選定していますか？また、その理由は何ですか？

ゲートとなる質問： ディメンション 4 は次の質問から始めます：「テストに AI ツールを使用していますか、または使用する予定ですか？」 回答に応じて分岐します：

• いいえ → 1～2 個の簡単な確認質問（最大 2 個。質問数の上限に含まれます）で確認し、ディメンションを「解決済み／該当なし」としてマークして先に進みます。AI 統合を行っていないチームに、AI に関する詳細な質問を無理に続けないでください。
• はい → AI に関する主要な質問（4.1～4.4）を行います。4.1 では、将来の計画ではなく、現在の利用状況を確認します。
• 曖昧（「評価中」「部分的に」「場当たり的に」「開発者は Copilot を使っているが、自動化はされていない」）→ はいとして扱い、主要な質問を行います。ただし、4.1 では実際の現在の利用状況に焦点を当てます。「評価した結果、採用しないことにした」という回答はいいえとして扱い、その理由を記録します。

はっきりしない回答自体が、詳しく確認すべき兆候です。Core Protocol ルール #5 に従い、「たぶん」を決定なしに受け入れてはいけません。

ディメンション 5：CI/CD パイプライン

• テストの各ステージと品質ゲートは何ですか？
• 実行予算はどのくらいですか？（ステージごとの制限時間）
• テストの選択方針は何ですか？（影響を受けるテスト、スマート選択、全テスト）
• 失敗時に即座に停止しますか、それともすべて実行してから報告しますか？
• CI で不安定なテストをどのように扱っていますか？（隔離、自動リトライ、マージのブロック）

AI 支援テストに関する質問のガイドライン

質問が AI 統合（ディメンション 4）に及び、ゲートとなる質問への回答で AI を使用していることが確認された場合は、さらに詳しく確認してください。検証されていない AI は、テストにおいて高いリスクがあります。質問の全リストについては、references/ai-testing-interrogation.md を参照してください。

主な確認事項：

• 検証： AI が生成したテストが、意図した対象を実際にテストしていることをどのように確認していますか？
• 決定性： 誤った理由でテストが成功する可能性はありますか？
• 保守： AI ツールが出力形式を変更した場合、どうなりますか？
• 責任者： テストの責任者は誰ですか？人間ですか、それとも AI ツールですか？
• 監査証跡： テストが存在する理由と、何を検証するのかを説明できますか？

アンチパターンと危険信号

厳しい質問をする際に、以下のアンチパターンを見つけて指摘してください。ユーザーの計画やコードベースに見つけたら、明確に名前を挙げ、その判断の背景を問い直してください。いずれも、テストスイートの品質を気づかないうちに低下させる、よくある失敗パターンです。

• ハードコードされた待機 — 自動待機や条件の代わりに Thread.sleep / page.waitForTimeout を使用します。競合状態を隠し、テストスイートの実行を遅くします。
• 脆弱なセレクター — nth-child、自動生成／ユーティリティの CSS クラス、または長い XPath チェーンです。テストスイートの劣化を招く最大の原因であり、無関係な DOM の変更でもテストが壊れます。
• 実行順序に依存するテスト — 特定の順序で実行した場合にしか通らないテストです。並列化を妨げ、実際のバグを見えにくくします。
• 逆ピラミッド型のテスト — E2E が 100％で、ユニットテストが 0％です。実行が遅く、コストが高く、不安定で、保守も困難です。
• 振る舞いではなく実装を検証する — ユーザーに見える振る舞いが重要なのに、内部状態や DB の行を検証します。機能が壊れていても通るテストを生みます。
• テストデータ戦略がない — ハードコードされた ID、共有状態、手動でのデータ投入です。予測不能なタイミングで失敗する不安定なテストを生みます。
• テストごとの全面的なログイン／新しいブラウザーコンテキスト — ストレージ状態を再利用せず、すべてのテストで認証のコストを丸ごと負担します。Playwright で最もよくあるパフォーマンス上の過ちです。
• 不安定さのテレメトリーがない — 測定していないものを隔離することはできません。不安定さの指標がないこと自体が危険信号です。
• 見栄えのためのカバレッジ指標 — リスクベースのカバレッジ（Dimension 1.2）ではなく、行カバレッジの％を追い求めます。重要でないパスを 100％カバーしても、誤った安心感を与えます。
• 並列化せず、文書化された予算を超えるテストスイート — テストスイートが合意済みの CI 予算（Dimension 5.2 を参照：PR は 5 分、マージは 15 分、夜間実行は 60 分）を超えているのにシャーディングされていない場合、それは規律の欠如であり、「後でランナーを追加しよう」という問題ではありません。
• AI が生成したテストをレビューなしでマージする — 検証されていない AI テストは、誤った理由で通過し、テストスイートへの信頼を損ないます。
• 不安定なテストを恒常的に無視する — 不安定さを P1 の兆候ではなく、当たり前のこととして扱います。テストスイートのシグナル対ノイズ比が崩壊します。

関連スキル

これらのスキルは、厳しい質問の後に続く実装を扱います。関連する場合は次のステップとして紹介してください。ただし、必須の依存関係にはしないでください。厳しい質問をすること自体は、それらに依存しません。

• Dimension 2（フレームワークとツール）→ playwright-e2e-testing、api-testing
• Dimension 3（テストアーキテクチャ）→ playwright-e2e-testing、playwright-regression-testing
• ライブブラウザーでの探索と証拠収集 → playwright-cli
• Dimension 4（AI 統合）→ ワークスペースで利用可能な AI ツール
• 全般的な計画とカバレッジ → qa-manual-istqb
• 回帰テストと横断的な品質 → playwright-regression-testing、a11y-playwright-testing、accessibility-selenium-testing
• Selenium チーム → webapp-selenium-testing、accessibility-selenium-testing

出力：テスト戦略決定記録（TSDR）

厳しい質問を行うセッションの最後に、すべての決定をまとめた TSDR を作成してください。用意されているテンプレートを使用します。

• Markdown： templates/grilling-summary.md — 開発者とバージョン管理向け
• HTML： templates/grilling-summary.html — 関係者、プレゼンテーション、共有向け

TSDR には以下が含まれます。

• プロジェクト名、日付、参加者
• 次元ごとのステータス（解決済み／保留／未解決）
• 決定ログ：質問、推奨回答、選択した回答、根拠
• 未完了項目とフォローアップアクション

プレースホルダーの計算式（MD と HTML の両方のテンプレートで統一して使用してください）：

• {{RESOLVED_COUNT}}、{{DEFERRED_COUNT}}、{{OPEN_COUNT}} は、5 つの次元のうち該当する数です。
• {{RESOLVED_PERCENT}} = RESOLVED_COUNT / 5 * 100（HTML のプログレスバーのみ）。DEFERRED と OPEN も同様です。3 つの割合の合計は 100 になります。

終了基準

次の場合は、質問セッションを終了します。

1. 5つのディメンションすべてを確認した場合（一部を保留にした場合も含む）
2. ユーザーが明示的に終了を求めた場合
3. 質問の上限（10～15問）に達し、残りの項目の優先度が低い場合
4. 残っている未解決の質問が、意思決定ではなく外部の依存関係によって保留になっている場合

ユーザーから求められない限り、ディメンションの途中で終了してはいけません。終了前に、必ず現在の状況を要約してください。

トーン

徹底的でありながら、建設的に進めてください。目的はユーザーを圧倒することではなく、隠れた前提を明らかにし、明確化を促すことです。すべての意思決定を重要なものとして扱いつつ、テスト戦略に最も大きな影響を与える質問を優先してください。

リスクを認識させずに、ユーザーが質問を飛ばすことを許してはいけません。質問を保留にする場合は、その旨を明記し、保留による影響を記録してください。