qe-holistic-testing-pact

PACTS の原則に基づくホリスティックテストモデル

<default_to_action> テスト戦略を設計したり、チームに品質を組み込んだりする際は、次の手順に従います。

1. PACTS の原則を適用します：Proactive（バグが発生する前にテストする）、Autonomous（チームが品質に責任を持つ）、Collaborative（チーム全体で責任を負う）、Targeted（リスクを重視する）、Structured（エージェントの動作に関するガバナンス、可観測性、説明可能性）
2. 重視するテストの象限を特定します：技術志向（ユニット、統合、パフォーマンス）またはビジネス志向（受け入れ、探索的、ユーザビリティ）
3. PACTS の側面とテストの象限に基づいてエージェントを選択します
4. 問題を数日ではなく数分で検出するフィードバックループを実装します
5. 活動（テスト数）ではなく、成果（バグ流出率、リリースへの確信度、エージェントの確信度）を測定します

PACTS の簡単な適用方法：

• Proactive → アーキテクチャにテスト容易性を組み込み、リファインメント時にリスク分析を行います
• Autonomous → 開発者がローカルでテストを実行し、手動の承認ゲートがない CI パイプラインを構築します
• Collaborative → Three Amigos、開発者と QE のペア作業、テストの責任を共有します
• Targeted → リスクベースの計画、重要なフローへの注力、価値のないテストの廃止を行います
• Structured → エージェントの動作に関するガバナンス、可観測性、説明可能性を確保し、信頼ではなく確信度を測定します

重要な成功要因：

• 品質は QA フェーズではなく、チーム全体の責任です
• QA は門番ではなく、支援役（インフラの構築、コーチング）です
• 開発中に迅速なフィードバックを得ることが重要であり、開発後ではありません </default_to_action>

クイックリファレンスカード

使用する場面

• 包括的なテスト戦略を設計するとき
• チームに品質文化を築くとき
• 新規プロジェクトのテストアプローチを選ぶとき
• 順次進行型の QA から、並行して進める品質活動へ移行するとき

PACTS の原則

原則	重視する点	アンチパターン
Proactive	コードを書く前にテストし、テスト容易性を設計します	バグが見つかるのを待ちます
Autonomous	チームは準備ができたらデプロイします	QA が手動の門番になります
Collaborative	チーム全体で品質を考えます	QA が孤立して作業します
Targeted	リスクベースで価値の高いテストを行います	チェック項目を網羅するためだけのテストを行います
Structured	エージェントの動作に関するガバナンス、可観測性、説明可能性	混乱した状態にエージェント型 AI を後付けします

ホリスティックテストの象限

象限	目的	例
技術 + 支援	迅速なフィードバック	ユニット、コンポーネント、統合テスト
技術 + 批判	限界の発見	パフォーマンス、セキュリティ、カオステスト
ビジネス + 支援	共通理解	BDD、受け入れテスト
ビジネス + 批判	未知の問題の発見	探索的テスト、ユーザビリティ、A/B テスト

PACTS + 象限に基づくエージェントの選択

PACTS の側面	エージェント
Proactive + 技術	qe-test-generator、qe-requirements-validator
Autonomous + 技術	qe-test-executor、qe-coverage-analyzer
Collaborative	qe-fleet-commander（オーケストレーション）
Targeted	qe-regression-risk-analyzer、qe-quality-gate
Structured	qe-fleet-commander、qe-quality-gate（ガバナンス、可観測性、説明可能性）

---

PACTS の実践

Proactive：バグが発生する前にテストする

// During API design, ask: "How will we know if this times out under load?"
// Build observability from start
await Task("Risk Analysis", {
  phase: 'refinement',
  question: 'What could go wrong and how will we know?'
}, "qe-requirements-validator");

Autonomous：チームが品質に責任を持つ

• 開発者がローカルでテストスイート全体を実行します
• CI は明確な診断情報を示して迅速に失敗します
• 手動のデプロイ承認はありません
• セルフサービスのテスト環境を用意します

Collaborative：チーム全体で考える

• QE が計画とリファインメントに参加します
• すべてのユーザーストーリーで Three Amigos を実施します
• テストコードの責任を共有します
• 複雑なシナリオではアンサンブルテストを行います

Targeted：重要なことをテストする

// E-commerce checkout? Test thoroughly.
// Admin panel used twice a month? Lighter touch.
await Task("Risk-Based Planning", {
  critical: ['checkout', 'payment'],
  light: ['admin-panel', 'settings']
}, "qe-regression-risk-analyzer");

構造化：ガバナンス、可観測性、説明可能性

エージェント型システムにおける5つ目の原則です。エージェントが品質業務を担うようになると、ガバナンス（境界とガードレール）、可観測性（エージェントが何を行い、その理由は何か）、説明可能性（監査できる意思決定）が必要になります。規制の厳しい業界では特に重要です。

• 信頼ではなく確信度を測定します — 信頼は人間の感情ですが、確信度は数学的に説明できます。
• プレイブックと準備状況評価ガイドが付属しています。
• アンチパターン：混乱した状態にエージェント型AIを継ぎ足すことです。まず構造を整え、その後に自動化します。

// Make agent behavior auditable and explainable, not a black box
await Task("Agent Governance Review", {
  guardrails: ['scope-boundaries', 'approval-gates'],
  observability: ['decision-traces', 'confidence-scores'],
  explainability: 'every-decision-auditable'
}, "qe-fleet-commander");

---

PACTからPACTSへ

PACTはReuven Cohen（Agentics Foundation）が考案し、Dragan Spiridonovが品質エンジニアリングに適用しました。PACTSでは、DORAによるAI支援デリバリーとプラットフォームエンジニアリングの品質測定に関する調査に着想を得て、5つ目の原則である構造化を追加しています。この追加は、自律的なエージェント型の品質業務を大規模に信頼できるものにするには、ガバナンス、可観測性、説明可能性が必要であることを反映しています。

---

従来のやり方からの進化

従来のやり方（逐次型）	全体最適＋PACTS（並行型）
開発者が作成 → QAがテスト → バグが見つかる → 修正	チームで何を作るか、どうテストするかを話し合う
フィードバックが遅く、責任のなすりつけ合いが起きる	フィードバックが速く、責任を共有する
品質は足止め役	品質は推進力
QAがクリティカルパス上にある	QAがインフラを構築し、コーチングを行う

---

成功の兆候

• 機能を1日に複数回デプロイしている
• バグの流出率が低下傾向にある
• チームが自然に品質について話し合っている
• 開発者が指示されなくてもテストを書く
• リリースが退屈である（良い意味で）

---

エージェント連携のヒント

メモリの名前空間

aqe/holistic-testing/
├── pacts-assessment/*    - PACTS maturity analysis
├── quadrant-coverage/*   - Coverage per quadrant
├── team-metrics/*        - Quality ownership metrics
└── feedback-loops/*      - Cycle time data

フリート連携

const holisticFleet = await FleetManager.coordinate({
  strategy: 'holistic-testing',
  pacts: { proactive: true, autonomous: true, collaborative: true, targeted: true, structured: true },
  agents: [
    'qe-fleet-commander',       // Orchestration
    'qe-test-generator',        // Tech quadrant
    'qe-requirements-validator', // Business quadrant
    'qe-quality-analyzer'       // Metrics
  ],
  topology: 'mesh'
});

---

関連スキル

• agentic-quality-engineering - エージェントの連携
• context-driven-testing - コンテキストに適応する
• shift-left-testing - プロアクティブなテスト
• risk-based-testing - 対象を絞ったテスト

---

忘れないでください

PACTS = プロアクティブ + 自律的 + 協調的 + 対象を絞る + 構造化

品質は後からテストするのではなく、組み込むものです。チームが品質に責任を持ちます。QAは品質を可能にしますが、足止めはしません。重要なものをテストし、重要でないものは省きます。可観測性と説明可能性を通じてエージェントの動作を統制し、信頼ではなく確信度を測定します。活動ではなく成果を測定します。

エージェントの活用： エージェントはPACTSの成熟度を分析し、各象限の適用範囲を推奨して、チーム全体の品質を調整します。人間の判断を維持しながら、全体最適の思考を広げるためにエージェントを活用します。