qe-context-driven-testing について
qe-context-driven-testingは、プロジェクトの目標、リスク、制約、チームのスキルに応じてテスト方法を選び、調整するためのスキルです。画一的な手法やスクリプト実行ではなく、調査と発見の記録を重視します。
主な機能
- 01プロジェクトの状況とリスクの分析
- 02制約とチームのスキルに応じたテスト調整
- 03探索的テストのヒューリスティクス活用
- 04発見事項と判断の記録
- 05状況に基づくエージェント連携
活用シーン
- 01新規プロジェクトのテスト方法の選定
- 02根拠が不明確なプロセスの見直し
- 03プロジェクトのリスクに沿った探索的テスト計画
- 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> テストの判断やアプローチの調整を行う際は、次の手順に従います。
- コンテキストを分析します。プロジェクトの目標、制約、リスク、チームのスキルを確認します
- 慣行に疑問を投げかけます。「なぜこれをするのか? どのようなリスクに対処するのか? コストはどのくらいか?」
- 確認だけでなく、調査します。ソフトウェアは問題を解決しているのか、それとも新たな問題を生み出しているのか?
- 「ベストプラクティス」ではなく、コンテキストに応じてアプローチを調整します
- あらかじめ書かれた計画ではなく、発見したことを記録します
コンテキストをすばやく分析する方法:
- ミッション:「重要な問題を、意味のある速さで見つけること」(「テストケースを実行すること」ではありません)
- リスク:安全性が重要なら厳格に、社内ツールなら軽めに対応します
- 制約:厳しいスケジュールのスタートアップと、コンプライアンスが求められる大企業では状況が異なります
- スキル:初心者には構造が必要ですが、エキスパートは直感的に調整できます
成功の重要な要因:
- どこでも通用する「ベストプラクティス」はありません。あるのは、コンテキストに合った良いプラクティスだけです
- テストは調査であり、スクリプトの実行ではありません
- コンテキストは変化するため、アプローチも変える必要があります </default_to_action>
クイックリファレンスカード
使用する場面
- 新しいプロジェクトのテストに関する判断を行うとき
- 「いつもこうしている」という定説に疑問を投げかけるとき
- 特定の制約に合わせてアプローチを調整するとき
- 探索的テストのセッションを行うとき
コンテキスト駆動の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
});
実践的なヒント
- まずリスクを評価する - 機能を列挙し、次の点を確認します:失敗する可能性はどのくらいか?失敗した場合、どれほど深刻か?テストはどれほど難しいか?
- 調査に時間制限を設ける - チェックアウトに2時間、エラー処理に30分、ブラウザーごとに15分
- 発見したことを記録する - 「無効なメールアドレスを入力して、エラーが表示されることを確認する」ではなく、「決済 API が400ではなく500を返し、ユーザーに見えるエラーが表示されない。バグを報告済み。」
- 人と話す - 開発者、ユーザー、サポート担当者、プロダクト担当者
- 他の人とペアを組む - 視点が異なれば、見つかるバグも異なります
関連スキル
- agentic-quality-engineering - コンテキストを考慮したエージェントの選択
- holistic-testing-pact - 全体論的なモデルをコンテキストに合わせて適用する
- risk-based-testing - コンテキストはリスク評価に影響する
- exploratory-testing-advanced - RST の手法
覚えておくこと
意思決定はコンテキストに左右されます。 万能なベストプラクティスはありません。熟練したテスターは、具体的な目標、制約、リスクに基づいて情報を得たうえで判断します。
あなたはテストスクリプトを実行するだけの人ではありません。チームがより良い製品を作れるよう支援する、熟練した調査者です。
エージェントを活用する場合: エージェントはコンテキストを分析し、戦略を適応させ、あなたの状況で何が有効かを学習します。重要な判断では人間の判断力を維持しながら、コンテキスト主導の思考を拡大するためにエージェントを活用しましょう。
コメント
Markdown 対応