context-driven-testing

コンテキスト主導のテスト

<default_to_action> テストの判断やアプローチの調整を行う際は、次の手順に従ってください。

1. コンテキストを分析します：プロジェクトの目標、制約、リスク、チームのスキル
2. 慣行に疑問を持ちます：「なぜこれを行うのか？ どのリスクに対処するのか？ コストはどれくらいか？」
3. 確認するだけでなく、調査します：ソフトウェアは問題を解決するのか、それとも新たな問題を生み出すのか？
4. 「ベストプラクティス」ではなく、コンテキストに応じてアプローチを調整します
5. あらかじめ決められた計画ではなく、発見したことを記録します

コンテキストを素早く分析するために：

• 使命：「重要な問題を、意味のある速さで見つけること」（「テストケースを実行すること」ではありません）
• リスク：セーフティクリティカルなものは厳格に、社内ツールはより軽量に
• 制約：厳しいスケジュールのスタートアップと、コンプライアンスが求められる企業は異なります
• スキル：初心者には体系的な構造が必要ですが、エキスパートは直感的に調整できます

成功のための重要な要素：

• どこでも通用する「ベストプラクティス」はありません。あるのは、コンテキストに合った適切なプラクティスだけです
• テストは調査であり、スクリプトの実行ではありません
• コンテキストは変化するため、アプローチも変える必要があります </default_to_action>

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

使用する場面

• 新しいプロジェクトのテストについて判断するとき
• 「そういうものだから」という定説に疑問を持つとき
• 特定の制約に合わせてアプローチを調整するとき
• 探索的テストのセッションを行うとき

RST ヒューリスティクス

ヒューリスティクス	適用方法
SFDIPOT	構造、機能、データ、インターフェース、プラットフォーム、運用、時間
オラクル	履歴、類似製品、期待、ドキュメントとの一貫性
ツアー	ビジネス地区、歴史、危険地帯、観光客、博物館

---

コンテキストに応じた判断

例：テスト自動化のレベル

スタートアップのコンテキスト：

• 小規模なチーム、頻繁な変更、プロダクトマーケットフィットが不明確
• 判断： 重要なパスは軽く自動化し、探索的テストを多く行う
• 理由： 要件の変更が速すぎて、大規模な自動化に対応できません

エンタープライズのコンテキスト：

• 機能が安定しており、規制要件があり、大規模なチーム
• 判断： 包括的な自動回帰テストスイートを用意する
• 理由： 安定性があれば、自動化への投資効果が得られます

例：ドキュメント

規制対象（FDA／医療）：

• 判断： 詳細なテストプロトコルとトレーサビリティマトリクスを用意する
• 理由： 規制コンプライアンスは任意ではありません

スピード重視のスタートアップ：

• 判断： 軽量なセッションメモとリスクログを使用する
• 理由： 官僚的な手続きは、役立つ以上に進行を遅らせます

---

エージェント支援によるコンテキスト主導のテスト

// Agent analyzes context and recommends approach
const context = await Task("Analyze Context", {
  project: 'e-commerce-platform',
  stage: 'startup',
  constraints: ['timeline: tight', 'budget: limited'],
  risks: ['payment-security', 'high-volume']
}, "qe-fleet-commander");

// Context-aware agent selection
// - qe-security-scanner (critical risk)
// - qe-performance-tester (high volume)
// - Skip: qe-visual-tester (low priority in startup context)

// Adaptive testing strategy
await Task("Generate Tests", {
  context: 'startup',
  focus: 'critical-paths-only',
  depth: 'smoke-tests',
  automation: 'minimal'
}, "qe-test-generator");

---

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

メモリ名前空間

aqe/context-driven/
├── context-analysis/*    - Project context snapshots
├── decisions/*           - Testing decisions with rationale
├── discoveries/*         - What was learned during testing
└── adaptations/*         - How approach changed over time

フリート連携

const contextFleet = await FleetManager.coordinate({
  strategy: 'context-driven',
  context: {
    type: 'greenfield-saas',
    stage: 'growth',
    compliance: 'gdpr-only'
  },
  agents: ['qe-test-generator', 'qe-security-scanner', 'qe-performance-tester'],
  exclude: ['qe-visual-tester', 'qe-requirements-validator']  // Not priority
});

---

実践的なヒント

1. リスク評価から始める - 機能を列挙し、次の点を確認します：失敗する可能性はどのくらいか？ 失敗した場合の影響はどれくらいか？ テストの難しさはどの程度か？
2. 探索の時間に上限を設ける - チェックアウトに2時間、エラーハンドリングに30分、ブラウザーごとに15分
3. 発見したことを記録する - 「無効なメールアドレスを入力し、エラーを確認する」ではなく、「決済 API が 400 ではなく 500 を返し、ユーザーに見えるエラーがない。バグを起票済み」
4. 人と話す - 開発者、ユーザー、サポート担当者、プロダクト担当者
5. 他の人とペアを組む - 視点が違えば、見つかるバグも異なります

---

関連スキル

• agentic-quality-engineering - コンテキストを踏まえたエージェントの選択
• holistic-testing-pact - 全体的なモデルをコンテキストに合わせて調整する
• risk-based-testing - コンテキストがリスク評価に影響する
• exploratory-testing-advanced - RST の手法

---

覚えておくこと

エージェントを使う場合： エージェントはコンテキストを分析し、戦略を調整し、それぞれの状況で有効な方法を学習します。エージェントを活用してコンテキスト主導の思考を拡張しつつ、重要な判断では人間の判断力を保ってください。