test-strategy

製品、チーム、リスクプロファイルに合わせた、実行可能な QA 戦略を作成します。日々のテストに関する意思決定を導くドキュメントであり、使われないコンプライアンス文書にはしません。E2E テストが 150 件あり、パイプラインに 52 分かかるチームは、十分なカバレッジがあると思っています。このスキルでは、逆ピラミッドを診断し、バランスを整える方法を提案し、すべての要素を測定可能な KPI に結び付けます。

---

ヒアリング項目

戦略を書き始める前に、状況を把握してください。まず .agents/qa-project-context.md を確認し、存在する場合はその内容を基盤として、すでに回答済みの質問は省略してください。

製品とビジネスの状況

• 製品は何ですか？（SaaS、e コマース、API プラットフォーム、モバイルアプリ、コンテンツサイト）
• ユーザーは誰ですか？（消費者、エンタープライズ、社内、開発者）
• ビジネス上重要なフローは何ですか？（サインアップ、チェックアウト、支払い、データエクスポート）
• リリース頻度はどのくらいですか？（継続的、毎週、隔週、四半期ごと）
• どのようなコンプライアンス要件がありますか？（SOC2、HIPAA、PCI-DSS、GDPR、EU AI Act）

現在のテスト状況

• 現在、どのテストレベルがあり、それぞれ何件ありますか？
• どのフレームワークやツールを使用していますか？
• 現在のコードカバレッジはどのくらいですか？目標があれば、その値も教えてください。
• CI パイプラインが最初から最後まで完了するまで、どのくらいかかりますか？
• 現在の不安定なテストの割合はどのくらいですか？

課題と目標

• 品質に関する最大の課題は何ですか？（リグレッション、フィードバックの遅さ、不安定なテスト、テストの抜け漏れ）
• 直近 3 回のリリースで何が壊れましたか？本番環境に流出した不具合は何ですか？
• このチームにとって「十分な品質」とはどのような状態ですか？
• テストインフラへの投資意欲はどの程度ありますか？

チームと制約

• チームの規模と構成を教えてください。（開発者、QA、SDET、手動テスター）
• 自動化ツールに関するスキルレベルはどの程度ですか？
• ツールに関する予算の制約はありますか？
• 期限によるプレッシャーはありますか？この戦略を策定するきっかけとなった期限はありますか？

---

チームの成熟度に合わせて調整してください（.agents/qa-project-context.md で team_maturity を設定します）。

• startup — 最小限のピラミッドとします。ユニットテストに加え、重要な E2E パスを少数用意します。CI が安定して実行されるまでは、コントラクトテストと正式なメトリクスは省略します。フェーズ 1 は 4 週間未満とします。
• growing — 定義済みのカバレッジ目標、不安定なテストのしきい値、CI 品質ゲートを備えた完全なピラミッドとします。リスクベースの優先順位付けを追加します。
• established — SLA に基づく品質ゲート、複数環境でのカバレッジ、高度なツール（コントラクトテスト、カオステスト、オブザーバビリティ）、正式なレビューサイクルを導入します。

---

基本原則

1. 網羅的なカバレッジより、リスクベースの優先順位付けを重視します。 すべてのコードが同じ重要度ではありません。支払い機能の不具合は、ツールチップの誤字の 1000 倍の損失をもたらします。テストの工数はコード量ではなく、ビジネスリスクに比例して配分します。リスクマトリックスを使って投資対象を決めます。まだマトリックスがない場合は、まず risk-based-testing を実行してください。

2. テストピラミッドの健全性は先行指標です。 健全なテストスイートは、実行の速いユニットテストが多く、インテグレーションテストがそれより少なく、E2E テストが最も少ない構成です。この形が逆転すると（アイスクリームコーン型になると）、フィードバックが遅く、メンテナンス負荷が高まり、逆説的に信頼性も低下します。何かを提案する前に、現在の形を診断してください。

3. シフトレフト：不具合をより早く検出します。 不具合の発見が遅れるほど、修正コストは指数関数的に増加します。静的解析をテストより先に、ユニットテストをインテグレーションテストより先に、コントラクトテストを E2E テストより先に行い、検証を前倒しします。設計レビューでは、テストだけでは見つけられないアーキテクチャ上の不具合を検出できます。

4. 戦略のすべての要素に KPI を設定します。 測定できなければ、改善もできません。カバレッジ目標、不安定なテストのしきい値、流出率の目標、MTTR の上限など、各セクションで数値と追跡頻度を明記します。

5. 棚にしまう文書ではなく、更新し続ける文書にします。 少なくとも四半期ごとに見直します。改訂履歴、セクションごとの担当者、明確な再評価の契機（新しい製品領域、チームの変更、重大インシデント、不具合の流出）を記載します。

---

戦略ドキュメントのテンプレート

各セクションを順に確認し、最終ドキュメントを作成します。複雑さに応じて内容の深さを調整してください。従業員5人のスタートアップに必要なのは5ページであり、50ページではありません。最終ドキュメントは、エグゼクティブサマリーから改訂履歴までの13セクションで構成します。コピー＆ペーストできるMarkdownのひな型については references/diagrams-and-worksheets.md を、SaaS、eコマース、APIファースト、メディアの4つの詳細な例については references/strategy-templates.md を参照してください。

1. 範囲と目標

境界を明確に定義してください。ここが曖昧だと、後の段階で抜け漏れや無駄な作業が発生します。

• 対象範囲： この戦略が対象とするすべての製品領域、サービス、連携機能、機能要件と非機能要件の種類、プラットフォーム、ブラウザー、デバイスを記載します。
• 対象外： 対象外とする内容とその理由を記載します。たとえば、契約レベルでのみテストするサードパーティサービスや、廃止予定のレガシーシステムです。
• 目標： 測定可能な目標を3～5個、期限とともに定めます。例：「2四半期以内に、欠陥流出率を12％から5％未満に減らす」「2026年第1四半期以降にリリースするすべてのサービスで、ユニットテストカバレッジ80％を達成する」。

2. テストレベルと種類

各レベルで何を検証するのか、誰が担当するのか、想定するテスト数を定義します。

レベル	検証内容	担当者	フレームワーク	目標数	実行頻度
ユニット	関数、ビジネスロジック、境界ケース	開発者	Vitest/Jest/pytest	全テストの70～80％	コミットごと
統合	サービス間の連携、DBクエリ、APIコントラクト	開発者＋QA	Supertest/pytest + Testcontainers	全テストの15～20％	PRごと
E2E	フルスタックを通じた重要なユーザージャーニー	QA/SDET	Playwright/Cypress	全テストの5～10％	デプロイ前＋毎晩
API	コントラクト準拠、スキーマ、エラー処理	開発者	Playwright APIRequestContext/Schemathesis	エンドポイントごと	PRごと
ビジュアル	UIのリグレッション、レイアウトのずれ、レスポンシブ対応	QA	Playwright/Argos/Chromatic	主要ページ	毎晩
パフォーマンス	応答時間、スループット、リソース使用量	DevOps/QA	k6/Lighthouse	重要なパス	毎週＋リリース前
セキュリティ	OWASP Top 10、依存関係の脆弱性、認証フロー	セキュリティ/DevOps	OWASP ZAP/Snyk	リリースごと	リリース前＋定期実行
アクセシビリティ	WCAG 2.2 AA、スクリーンリーダーとの互換性	QA/フロントエンド	axe-core	主要なフロー	PRごと

製品の実際のニーズに合わせて調整してください。ビジュアルリグレッションが不要な製品もありますが、ユニットテストと統合テストはすべての製品に必要です。

3. テストピラミッドの分析

現在の形を診断し、目標を定義します。

形状。 テストスイートは、健全なピラミッド（単体テストが多く、E2E テストが少ない）、アイスクリームコーン（逆ピラミッド型で、E2E テストが多い）、ダイヤモンド型（統合テストが多い）、砂時計型（単体テストが多く、E2E テストが少ない一方で、統合テストが不足している）の4つの形状のいずれかを取ります。それぞれ、フィードバックと保守性のトレードオフが異なります。形状を並べて比較した ASCII 図については、references/diagrams-and-worksheets.md を参照してください。

現在の状態。 各レベルのテスト数を数えて割合を算出し、形状を特定したうえで、CI の所要時間、フレーク率、合格率を記録します。リファレンスファイルにある「現在の状態の評価ワークシート」を参照してください。

目標の状態。 具体的な件数とともに目標比率（単体テスト70～80％、統合テスト15～20％、E2E テスト5～10％）を定め、CI の目標所要時間とフレーク率も設定します。「目標の状態ワークシート」を参照してください。

アクションプラン — アイスクリームコーン型またはダイヤモンド型の場合：

1. E2E テストの増加を凍結する — 新たなクリティカルパスをカバーする場合を除き、新しい E2E テストを追加しません。
2. 既存の E2E テストを分解する — 単体テストレベルで検証可能なロジックを検証している E2E テストを見つけ、より下位のレベルに書き換えます（税額計算を検証する購入手続きのテストは、税額計算関数の単体テストにします）。
3. PR チェックリストに単体テストの要件を追加する — ビジネスロジックに触れるすべての PR に単体テストを含めます。
4. CI ゲートを設定する — 単体テストと E2E テストの比率がしきい値を下回る PR を失敗させます。

バランスを調整する前に、本当にフレークしている E2E テストと、実際のバグを明らかにしているテストを区別してください、競合状態を隠すフレークテストを隔離すると、リグレッションがすり抜けてしまいます。フレークの根本原因のトリアージと隔離の仕組みについては、test-reliability を参照してください。

アクションプラン — 砂時計型の場合：

1. 統合テストのインフラに投資する — DB フィクスチャ、サービススタブ、コントラクトテストを整備します。
2. サービス境界を特定する — 各境界に、正常系とエラーケースの統合テストが必要です。
3. コントラクトテスト（Pact）を使ってサービス間通信をテストします。

4. リスク評価マトリクス

機能をリスクレベルに対応付けます。これはテストの深さを直接決定します。各機能の影響度（1：無視できる → 5：壊滅的）× 発生可能性（1：まれ → 5：ほぼ確実）をスコア化し、その積（1～25）を LOW／MED／HIGH／CRIT の各区分に対応付けます。すべてのセルにラベルを付けた5x5の完全なマトリクスについては、references/diagrams-and-worksheets.md を参照してください。

リスクレベル	テストの対応	自動化	モニタリング
CRITICAL (15-25)	完全な自動化 + 手動の探索的テスト + 負荷テスト	必須、コミットごと	リアルタイムアラート、合成モニタリング
HIGH (10-14)	完全な自動化 + 定期的な手動レビュー	必須、PR ごと	ダッシュボード + 毎日の確認
MEDIUM (5-9)	正常系 + 重要なエラーケースを自動化	推奨	毎週レビュー
LOW (1-4)	手動テストまたは省略	任意	不要

対応付けの例：

機能領域	影響度	発生可能性	スコア	テスト方法
決済処理	5 - 壊滅的	3 - 起こり得る	15 - CRIT	自動 E2E + 単体 + コントラクト + モニタリング
ユーザー認証	5 - 壊滅的	2 - 起こりにくい	10 - HIGH	自動 E2E + セキュリティスキャン + 単体
商品検索	3 - 中程度	3 - 起こり得る	9 - MED	単体 + 統合 + 正常系 E2E
ダッシュボードの描画	2 - 軽微	3 - 起こり得る	6 - MED	単体 + ビジュアルリグレッション
メール設定	1 - 無視できる	2 - 起こりにくい	2 - LOW	手動で確認

5. 環境戦略

環境	目的	テストの種類	データ	デプロイのトリガー
ローカル	開発者へのフィードバック	ユニット、統合	モック／シード済み	保存時
CI	自動検証	ユニット、統合、Lint、SAST	一時的	プッシュ／PR 時
ステージング	本番前の検証	E2E、ビジュアル、パフォーマンス、セキュリティ	本番に近い（匿名化済み）	main へのマージ時
本番	モニタリングとスモークテスト	スモークテスト、合成モニタリング	ライブ	デプロイ時

環境ごとのテストデータの管理方法、環境が一時的なもの（プレビューデプロイ）か長期運用されるものか、アクセス権を持つユーザー、環境固有の設定の管理方法を文書化してください。

6. ツール選定の根拠

最初にツールを選ぶのではなく、ニーズを把握してから、それに適したツールを選んでください。重み付けした基準で候補をそれぞれ評価します。

基準（重み）	ツール A	ツール B	ツール C
技術スタックとの適合性（25%）
チームの習熟度（20%）
コミュニティとドキュメント（15%）
CI との連携（15%）
保守コスト（10%）
実行速度（10%）
ライセンス費用（5%）
加重合計

各項目を 1～5 で採点し、重みを掛けて合計し、加重合計を算出します。ライセンス費用だけでなく、総保有コストも考慮してください。具体的には、セットアップ時間（CI の設定、最初のテストの作成、チームのトレーニング）、作成時間（実際のテストを 5 件作成して測定）、保守時間（フレームワークの更新時にテストがどれほど頻繁に壊れるか）、デバッグ時間（適切なエラーメッセージがあれば短縮できます）、インフラコスト（ブラウザーファーム、並列ランナー）です。

一般的なスタックの出発点 — 選択した理由や、ここから逸脱した理由を文書化してください。

製品タイプ	ユニット	統合	E2E	API	ビジュアル
React SaaS	Vitest	Testing Library + MSW	Playwright	Supertest	Playwright のスクリーンショット
Next.js	Vitest	Testing Library + MSW	Playwright	Supertest	Playwright のスクリーンショット
Python API	pytest	pytest + Testcontainers	pytest + requests	Schemathesis	該当なし
モバイル（RN）	Jest	Testing Library + MSW	Detox / Maestro / Appium 3.x	Supertest	Appium のスクリーンショット
Vue SaaS	Vitest	Testing Library + MSW	Playwright	Supertest	Playwright のスクリーンショット
AI/LLM 機能	Vitest	DeepEval	Playwright + Promptfoo 評価	Promptfoo / Ragas	該当なし

AI/LLM 機能では、幻覚、バイアス、プロンプトインジェクション、プライバシーについて明示的なリスクテストを追加してください。ai-system-testing と compliance-testing（EU AI Act）を参照してください。

参考フレームワーク：

• CTAL-AT v2.0（ISTQB、アジャイルテスター上級、2026）— CTFL v4.0 を前提条件とする新しい上級レベルの認定資格であり、上級レベルの旧資格の更新版ではありません。廃止された基礎レベルの CTFL-AT アジャイル拡張に取って代わるもので（すでに CTFL v4.0 に統合済み）、テスト戦略とアプローチ、チーム全体での取り組み、シフトレフト、エンドツーエンドテスト、テストスメル、探索的テストおよび AI 支援テストを扱います。
• CT-GenAI v1.1（ISTQB、2026-04-27 リリース）— LLM を活用したテストインフラを専門分野として体系化し、AI 固有のリスク分類（幻覚、推論エラー、バイアス、プライバシー、AI 規制）を定義します。
• CTFL v4.0（ISTQB）— 基礎的な用語集です。異なるテスト手法を採用するチーム間で認識をそろえる際に役立ちます。
• HTSM v6.3（Bach）— ヒューリスティック・テスト戦略モデルです。状態ベースのテストと境界値のヒューリスティックを重視します。ISTQB の枠組みに代わる軽量な選択肢です。
• World Quality Report 2025-26（Capgemini、第 17 版）— ベンチマークデータによると、QA で Gen AI を試験的に導入している組織は 43%、本格展開している組織は 15% です。計画時に AI 導入の段階を把握するのに役立ちます。

7. CI のスケーリング手段

テストスイートやチームが大きくなると、CI の所要時間が戦略を破綻させる制約になります。テストを削除する前に、次の手段を検討してください。

• シャーディング — テストスイートを N 個の並列ランナーに分割します（Playwright の --shard=1/4、Jest の --shard、pytest-xdist、Cypress の並列化）。シャードごとの固定コスト（インストール、ビルド）が支配的になるまでは、速度が線形に向上します。
• テスト影響分析 — すべての PR でテストスイート全体を実行する代わりに、差分の影響を受けるテストだけを実行します。依存関係グラフ（Nx の affected、Vitest の --changed、Bazel）またはカバレッジとファイルの対応表を使います。テストの劣化を防ぐため、夜間またはマージ時のゲートではテストスイート全体を実行してください。
• キャッシュ — 実行間で依存関係、ビルド成果物、ブラウザーバイナリをキャッシュします。
• PR では E2E を選択的に実行 — PR ではスモーク E2E を実行し、マージ時または夜間に E2E 全体を実行します。

効果は推測せず、測定してください。並列効率 = テスト実行時間の合計 ÷ 実時間です。シャード数に近い値（例：4 シャードで 3 倍超）を目標にします。値が低い場合は、固定セットアップコストや実行時間の長いテストが速度向上を妨げています。実時間を短縮する一方で、課金対象の計算量を膨らませる並列化を把握するため、PR あたりの CI 分数を追跡してください。

8. 開始／終了条件

各レベルで、テストを開始する前に満たすべき条件（開始条件）と、完了前に満たすべき条件（終了条件）を定義します。

ユニットテスト — 開始条件：コードがコンパイルされ、関数の契約（入出力）が文書化されていること。終了条件：すべての分岐をカバーし、エッジケースをテストし、スキップされたテストがなく、カバレッジ目標を達成していること。

インテグレーションテスト — 開始条件：ユニットテストに合格し、依存サービスが利用可能またはスタブ化され、テストデータが投入されていること。終了条件：すべてのサービス境界をテストし、エラーパスを検証し、不安定なテストがないこと。

E2E — 開始条件：インテグレーションテストに合格し、ステージング環境にデプロイされ、テストアカウントが準備されていること。終了条件：重要なユーザージャーニーがすべて成功し、未解決の P0／P1 の不具合がなく、パフォーマンスが SLA の範囲内であること。

リリース — 開始条件：すべてのテストレベルに合格し、未解決の CRITICAL／HIGH の不具合がなく、リリースノートが作成されていること。終了条件：本番環境でスモークテストに合格し、合意した監視期間（30 分が妥当な初期値です。デプロイ頻度やアラートの遅延に応じて調整してください）に異常がないことを監視で確認し、ロールバック計画を検証していること。

9. 品質ゲートと完了の定義

不良なコードが先に進むのを防ぐ自動ゲートです。

PR ゲート（すべての PR）：ユニットテストに合格すること、インテグレーションテストに合格すること、カバレッジが低下しない（または最低基準を満たす）こと、新しい lint エラーがないこと、SAST スキャンに合格する（新たな高／重大の問題がない）こと、バンドルサイズがしきい値内であること、少なくとも 1 人のレビュアーが承認していること。

マージゲート（main へのマージ時）：PR ゲートのチェックすべてに合格すること、プレビュー環境に対する E2E スモークテストに合格すること、マージ競合がないこと、ブランチが main の最新状態であること。

デプロイゲート（本番環境へのデプロイ前）：ステージング環境で E2E テストスイート全体に合格すること、パフォーマンスベンチマークが範囲内であること、セキュリティスキャンに合格すること、フィーチャーフラグが設定されていること、ロールバック計画が文書化され、テスト済みであること。

夜間ゲート（定期実行）：エッジケースを含む E2E テストスイート全体、ビジュアルリグレッション、パフォーマンス／負荷テスト、アクセシビリティスキャン、依存関係の脆弱性スキャンを実行します。結果は翌朝、QA リードが確認します。

各ゲートには具体的な合格／不合格のしきい値を定め、CI で強制してください。クリックして通過できるゲートは、ゲートではなくドキュメントです。

10. メトリクスと KPI

メトリクス	定義	目標	頻度
コードカバレッジ	ユニットテストと統合テストでカバーされる行／分岐	重要なサービスでは >80%、全体では >60%	PR ごと
テストピラミッド比率	ユニットテスト：統合テスト：E2E の割合	70:20:10（許容誤差 ±10%）	毎月
不安定率	非決定的な失敗が発生した実行の割合	<2%	毎週
欠陥流出率	本番環境で見つかった欠陥の全欠陥に対する割合	<5%	リリースごと
MTTR	検出から修正のデプロイまでの時間	P0 は <4h、P1 は <24h	インシデントごと
CI パイプライン所要時間	プッシュから成功／失敗のシグナルまで	PR は <15 分、全体は <30 分	毎週
CI 並列実行効率	テスト時間の合計 ÷ 実経過時間	シャード数に近づける（4 シャードで >3 倍）	毎週
PR あたりの CI 分数	PR 実行あたりの課金対象コンピューティング時間（分）	横ばい、または減少	毎月
欠陥密度	1000 LOC あたりの欠陥数	減少傾向	毎月
自動化率	自動化されたテストケースの割合	リグレッションテストスイートで >80%	四半期ごと
誤検知率	実際のバグではない失敗の割合	<5%	毎週

メトリクスの活用： 絶対値ではなく、経時的な推移を追跡してください。カバレッジを 30% から 60% に伸ばしたチームは素晴らしい成果を上げています。現在の状況に基づいて現実的な目標を設定してください（1 四半期で 20% から 90% は計画ではなく夢物語です）。四半期ごとにリーダーシップとレビューし、改善を称えましょう。急増を調査してください。不安定率の急な上昇は、怠慢ではなくインフラに原因があることを示しています。チームを罰するためにメトリクスを使ってはいけません。KPI の定義、DORA メトリクス、ダッシュボードの詳細については qa-metrics を参照してください。

11. タイムラインとマイルストーン

段階的に展開してください。すべてを一度に実施すると、何もきちんと完了しません。

フェーズ 1 — 基盤（第 1〜4 週）： すべてのプロダクト領域のリスク評価、ユニットテストのゲートを備えた CI パイプライン、ベースラインメトリクス（カバレッジ、不安定率、パイプライン所要時間）、リスクの高い上位 5 領域のユニットテスト、E2E フレームワークの選定と設定。終了条件：CI がすべての PR でユニットテストを実行し、ベースラインメトリクスが文書化されていること。

フェーズ 2 — カバレッジの拡大（第 5〜10 週）： すべてのサービス境界に対する統合テスト、重要なジャーニー上位 10 件の E2E テスト、主要ページのビジュアルリグレッションテスト、テストデータ管理、夜間実行。終了条件：すべての重要なパスが E2E でカバーされ、統合テストがすべての API をカバーしていること。

フェーズ 3 — 品質ゲート（第 11〜14 週）： PR におけるカバレッジゲート（低下を許可しない）、CI でのパフォーマンスベンチマーク、セキュリティスキャン、すべての KPI の監視ダッシュボード。終了条件：4 つのゲート（PR、マージ、デプロイ、夜間）がすべて有効化され、適用されていること。

フェーズ 4 — 最適化（第 15〜20 週）： 不安定なテストの修正または隔離、CI のスケーリング施策（シャーディング、キャッシュ、テスト影響分析）、本番環境での合成監視、初回の四半期戦略レビュー。終了条件：CI が 15 分未満、不安定率が 2% 未満となり、初回の戦略改訂版が公開されていること。

継続的な取り組み： 四半期ごとの戦略レビューと改訂、毎月のメトリクスレビュー、継続的な保守（リファクタリング、不安定性の解消、廃止）。

---

アンチパターン

カバレッジ 100％を目標にする。 80％を超えると効果は次第に薄れます。残りの 20％を達成するには、実際のバグが潜む統合上の抜けを無視して、ゲッターや単純なコードをテストすることになります。一律の数値ではなく、リスクに応じてモジュールごとにカバレッジを設定してください。

アイスクリームコーン（逆ピラミッド）。 E2E が多すぎて、単体テストが少なすぎます。症状として、CI に 45 分以上かかる、UI を変更するたびにテストが壊れる、誰もテストスイートを信頼していない、といったことが挙げられます。E2E の増加を止め、既存の E2E テストを下位レベルに分解して解消してください。

戦略を一度きりの文書にする。 一度書いて更新しないのは、何もないより悪いことです。誤った安心感を与えるからです。定期レビューのきっかけを設けましょう。四半期ごとのカレンダーレビュー、インシデント発生後、新しい製品領域の追加、チーム構成の変更などです。

ツール優先の考え方。 「Playwright を使うべきです」は、計画を装ったツール選定です。まず何を検証する必要があるかを明確にし、次にそれに適したツールを選んでください。この文書ではツール選定の根拠を示しますが、ツールの話から始めてはいけません。

指標がなければ説明責任もない。 測定可能な目標がない戦略は、単なる願望リストです。すべてのセクションを KPI に結び付けてください。成功を数値で定義できない場合は、その要素を含める必要があるか検討してください。

テストを孤立させる。 QA ウィキにしかない戦略は、開発者の目に触れません。PR テンプレート、CI ゲート、完了の定義に組み込む必要があります。開発者が日常的に目にしなければ、その戦略は存在しないも同然です。

他社の戦略をコピー＆ペーストする。 他社の戦略をそのまま採用すると、自社のリスク特性、チームのスキル、制約が無視されます。テンプレートは出発点です。すべてのセクションを自社に合わせて調整してください。

すべてをすぐに自動化する。 手動の探索的テストには、特に初期段階で大きな価値があります。リグレッションは自動化し、探索的テストは手動のままにしてください。何を手動のままにするか、そしてその理由を戦略に明記してください。

---

検証

完成と見なす前に、作成した文書に不足がないことを確認してください。保存した戦略ファイルに対して次を実行します。

DOC=docs/qa-strategy.md
# 1. All 13 numbered section headings present (Executive Summary → Revision History)
grep -cE '^### [0-9]+\.' "$DOC"          # expect 13
# 2. Every row in the Metrics & KPIs table has a non-empty Target cell
#    (no "| | " gaps in the target column) — visually scan the table block:
grep -nE '^\|' "$DOC" | grep -iE 'target|coverage|flak|mttr|escape'
# 3. A revision history and a named owner exist
grep -niE 'revision history|owner:' "$DOC"

次に、ピラミッドの比率を手計算で確認します。unit％＋integration％＋E2E％の合計は約 100％になるはずです。文書でシャーディングを推奨する場合は、「Metrics」表に並列実行の効率または CI の所要時間の目標があることを確認してください。指標のない最適化は推測にすぎません。

---

完了条件

• 合意済みのパスに戦略文書があり、grep -cE '^### [0-9]+\.' の結果が 13 である（Executive Summary から Revision History まで、すべてのセクションが記入されている）。
• テストピラミッドの目標比率が具体的な件数と達成までのスケジュールとともに定義されており、unit＋integration＋E2E の割合の合計が約 100％である。
• 各レベル（unit、integration、E2E、release）の開始基準と終了基準が記載されている。
• ツール選定について、ツール名を並べるだけでなく、スコアと重み付けを含む根拠マトリックスが記載されている。
• 4 つの各ステージ（PR、merge、deploy、nightly）に品質ゲートが定義され、それぞれに具体的な合否基準がある。
• Metrics & KPIs のすべての行に、空欄ではない Target と追跡頻度が記載されている。

関連スキル

• risk-based-testing — 最初に実施してください。リスク評価の方法論と AI／LLM 固有の障害クラスを詳しく扱います。このスキルでは、そのマトリックスを利用します。
• test-planning — 単一のスプリントまたはリリースの計画にはこちらを使用してください。test-strategy はその上位に位置する、複数四半期を対象とした全体的な方針です。
• test-reliability — ピラミッドの再調整ステップで参照する、フレークの根本原因のトリアージ、自己修復ロケーター、隔離の仕組みを扱います。
• qa-metrics — KPI の完全な定義、DORA メトリクス、テスト影響分析、ダッシュボード、傾向分析を扱います。
• release-readiness — Go／No-Go チェックリスト、カナリア分析、リリース信頼度のスコアリングを扱います。
• ci-cd-integration — パイプラインの設定、ゲートの実装、スマートシャーディングの設定を扱います。
• shift-left-testing — 検証をより早い段階に移すための手法を扱います。
• ai-system-testing — 戦略が AI／LLM 機能を対象とする場合に使用し、評価スイートのレイヤーを定義します。
• compliance-testing — 規制対象のユーザー向けの戦略（GDPR、EU AI Act、EAA、米国の州法）に使用します。

参考ファイル（references/ 内）

• diagrams-and-worksheets.md — ピラミッド型の図、現状／目標状態のワークシート、5x5 のリスクマトリックス全体、および13セクションの出力テンプレート。
• strategy-templates.md — 4つの完成済み戦略ドキュメント（SaaS、Eコマース、APIファースト、メディア）、段階的なピラミッド分析ワークシート、およびリスクマトリックスの機能一覧テンプレート。