mcpField
Q
qe-context-driven-testing

qe-context-driven-testing

github.com/proffesor-for-testingテスト・品質51986 回インストール今日更新
リポジトリ

qe-context-driven-testing について

qe-context-driven-testingは、プロジェクトの目標、リスク、制約、チームのスキルに応じてテスト方法を選び、調整するためのスキルです。画一的な手法やスクリプト実行ではなく、調査と発見の記録を重視します。

主な機能

  1. 01プロジェクトの状況とリスクの分析
  2. 02制約とチームのスキルに応じたテスト調整
  3. 03探索的テストのヒューリスティクス活用
  4. 04発見事項と判断の記録
  5. 05状況に基づくエージェント連携

活用シーン

  1. 01新規プロジェクトのテスト方法の選定
  2. 02根拠が不明確なプロセスの見直し
  3. 03プロジェクトのリスクに沿った探索的テスト計画
  4. 04制約の変化に応じたテスト方法の調整

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/proffesor-for-testing/agentic-qe --skill qe-context-driven-testing

インストール後、Claude Code で/qe-context-driven-testingを入力して読み込まれたか確認します。

詳細

コンテキスト駆動テスト

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

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

コンテキストをすばやく分析する方法:

  • ミッション:「重要な問題を、意味のある速さで見つけること」(「テストケースを実行すること」ではありません)
  • リスク:安全性が重要なら厳格に、社内ツールなら軽めに対応します
  • 制約:厳しいスケジュールのスタートアップと、コンプライアンスが求められる大企業では状況が異なります
  • スキル:初心者には構造が必要ですが、エキスパートは直感的に調整できます

成功の重要な要因:

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

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

使用する場面
  • 新しいプロジェクトのテストに関する判断を行うとき
  • 「いつもこうしている」という定説に疑問を投げかけるとき
  • 特定の制約に合わせてアプローチを調整するとき
  • 探索的テストのセッションを行うとき
コンテキスト駆動の7つの原則
  1. あらゆるプラクティスの価値は、そのコンテキストによって決まります
  2. コンテキストに合った良いプラクティスはありますが、普遍的なベストプラクティスはありません
  3. 協力して働く人々が最も重要です
  4. プロジェクトは予測できない形で進行します
  5. プロダクトは問題を解決するものです。問題が解決されなければ、プロダクトは失敗です
  6. 優れたテストは、知的な挑戦を伴う作業です
  7. 適切なタイミングで適切なことを判断するには、判断力とスキルが必要です
コンテキスト要因
要因確認事項
プロジェクトビジネス目標は? ユーザーのニーズは? 失敗の影響は?
制約スケジュールは? 予算は? チームのスキルは? レガシーシステムは?
リスク安全性が重要か? 規制対象か? 大量のトラフィックがあるか?
技術技術スタック固有の注意点は? 統合先は? 可観測性は?
RST ヒューリスティック
ヒューリスティック適用方法
SFDIPOT構造、機能、データ、インターフェース、プラットフォーム、運用、時間
オラクル履歴、類似プロダクト、期待、ドキュメントとの一貫性
ツアービジネス地区、歴史、危険地区、観光、博物館

コンテキストに基づく判断

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

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

  • 少人数のチーム、頻繁な変更、プロダクトと市場の適合性が不明確
  • 判断: 重要な経路は軽めに自動化し、探索的テストを重点的に行います
  • 理由: 要件の変化が速すぎるため、広範な自動化は適しません

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

  • 機能が安定しており、規制要件があり、大規模なチーム
  • 判断: 包括的な自動リグレッションテストスイートを用意します
  • 理由: 安定した環境であれば、自動化への投資効果が得られます
例:ドキュメント

規制対象(FDA/医療):

  • 判断: 詳細なテストプロトコルとトレーサビリティマトリクスを用意します
  • 理由: 規制への準拠は任意ではありません

変化の速いスタートアップ:

  • 判断: 簡潔なセッション記録とリスクログを用意します
  • 理由: 官僚的な手続きは、役立つ以上に進行を遅らせます

調査と確認の違い

確認テスト(調査)
API は 200 を返したか?API はユーザーのニーズを満たしているか?
ボタンは動作するか?負荷がかかったときに何が起きるか?
仕様と一致しているか?問題を解決しているか?

コンテキスト駆動ではない兆候

  • 「いつもこうしているから」という理由でプロセスに従う
  • 何かをする「理由」を説明できない
  • 見つけた問題ではなく、実行したテストケースの数を測定する
  • テスト計画がどのプロジェクトにもそのまま適用できる
  • スクリプトができた時点で考えるのをやめる

エージェント支援によるコンテキスト駆動テスト

// 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. 他の人とペアを組む - 視点が異なれば、見つかるバグも異なります

関連スキル


覚えておくこと

意思決定はコンテキストに左右されます。 万能なベストプラクティスはありません。熟練したテスターは、具体的な目標、制約、リスクに基づいて情報を得たうえで判断します。

あなたはテストスクリプトを実行するだけの人ではありません。チームがより良い製品を作れるよう支援する、熟練した調査者です。

エージェントを活用する場合: エージェントはコンテキストを分析し、戦略を適応させ、あなたの状況で何が有効かを学習します。重要な判断では人間の判断力を維持しながら、コンテキスト主導の思考を拡大するためにエージェントを活用しましょう。

コメント