MCPプロンプトのベストプラクティス

正確な用語を使用して、何をしたいのかを正確に説明してください。プロジェクト、フォルダー、テスト ケース名などの関連するコンテキストを含めます。

良い例：

「前回の回帰テストから失敗したテストケースを表示する。」

「QA ワークスペースでログインフローのテストケース実行する。」

曖昧なプロンプトは避けてください。

「テストを確認する。」

「何かを実行する。」

MCPがどこで何に対処すべきか理解できるように手助けします。関連する場合は、プロジェクト名、テストケースID、または時間枠を含めます。

良い例：

「なぜオーバーナイト回帰テストが失敗したのか？QAワークスペースで結果 IDabc-123を確認しています。」

「昨日のスモークテストと今日のフィーチャーブランチ実行の結果を比較する。」

広く始めて、進むにつれて焦点を絞ります。これにより、MCPはよりターゲットを絞った結果を提供することができます。

フローの例：

「最近のテスト結果を表示する。」→概要

「先週の失敗したテストに焦点を当てる」→フィルター

「決済サービスの障害の原因は？」→分析

「そのエラーに対する修正案を提案。」→行動

大きなタスクや複数のステップからなるタスクを分解し、MCPが効果的に処理できるようにします。

以下の代わりに：

「パフォーマンス問題に関するすべての情報を提供し、完全な報告書を作成」

以下を使用：

「以下を使用してパフォーマンスの要約レポートを作成：

• 結果XYZからの指標

• 前回のベースラインとの比較

• 検出されたボトルネック

• 最適化の推奨事項

• エグゼクティブサマリーの形式」

構造：[質問] + [コンテキスト] + [望ましい行動]

例：

「失敗したステップの原因とは？[質問]

今週の回帰テスト [内容] の「チェックアウトフロー」テストケースについて。[コンテキスト]

結果を分析し、エラーを修正する方法を提案 [行動]。」

構造： [特定の指標] に焦点を当てて、[アイテムA] と [アイテムB] を比較

例：

「ユーザー登録」と「ログイン」のテストケースを比較 [項目 A/B]

失敗したステップの数と実行時間に焦点を当てる [特定の指標]。

最近の実行において、どちらがより安定性を示しているかを強調。」

構成： [問題の説明] + [背景] + [調査リクエスト]

例：

「回帰フォルダー に「支払い検証」モジュールがない。[問題の説明]

構造によれば、これは 'Release1' の下にあるはずだ [コンテキスト] 。

どこに移動されたのかを調べて正しい組織に戻してください。[調査リクエスト]」

構成：[特定の要素] を含み、 [オーディエンス] のために [レポートタイプ] を作成

例：

QAチームのために要約レポートを作成し、以下を含めます：

最新のプレイリスト実行結果

合格したテストケースと失敗したテストケースの数

上位三つの繰り返し発生するテスト失敗

次回の回帰サイクル改善のための推奨事項。」

「利用可能なすべてのワークスペースを表示」

「MCP-demo」という名前のワークスペースを検索する」

「ワークスペース[ワークスペース名]の詳細を表示」

「ワークスペース[ワークスペース名] 内のすべてのテストケースを表示」

前の文脈を考慮して、短いプロンプトを使用することができます。

「すべてのテストケースを一覧表示」

「ワークスペース[ワークスペース名] 内の [テストケース名] に関連するすべてのテストケースを検索」

「ワークスペース[ワークスペース名] のテストケース [テストケース名] の詳細を表示」

「[フローの名前]フローのテストケースを作成」

「私の [テストケース名] テストケースを改善」

「[テストケース名] テストケースのエラーを表示」

「[テストケース名] テストケースのステップの名前を標準的な命名に変更」

「[テストケース名]テストケースのテストステップのラベルを整理」