mabl MCP は、多数の機能を備えており、その範囲は今も拡大し続けています。ツールをより使いやすくするため、このリファレンスでは、それらを代表的ないくつかのワークフローにまとめ、最大限に活用できるようにしています。これらのプロンプトを使用する際は、次の点に留意してください。
- これらは出発点となるプロンプトであり、一度きりのコマンドではありません。mabl MCP で最良の結果を得るには、対話を重ねることが重要です。状況と目的を伝え、エージェントのアプローチを確認し、そこから調整していきます。
- ワークフローに他の MCP と組み合わせるという注記がある場合は、課題管理ツール、デザインツール、コードベースなど、チームがすでに使用している他のツールと mabl を連携させる方法を説明しています。
次の目次から、試したいワークフローに移動できます。
- mabl MCP を使い始める
- 要件から新しいブラウザテストを作成する
- テストの要件に対するカバレッジギャップを確認する
- コンプライアンスのために mabl テストを Xray にマッピングする
- リリース前にプレビュー URL またはブランチ URL に対してテストを実行する
- 朝の品質スタンドアップを実行する
- エビデンスを使って単一の失敗テストを深掘りする
- PR がオープンな間に失敗したデプロイメントをトリアージする
mabl MCP を使い始める
mabl MCP サーバーに接続しました。どのようなことができますか。質問できる例をいくつか教えてください。その後、現在の状況を把握したいので、私のワークスペース、アプリケーション、最新のテスト実行を一覧表示してください。
想定される動作: 簡単なオリエンテーションが行われます。エージェントが質問の例をいくつか提案し、続いてワークスペース、アプリケーション、最近のテスト実行のスナップショットを返します。読み取り専用の操作のため、何も変更されません。
会話の次のステップ:
- 1 つのワークスペースの最近のアクティビティを詳しく確認する
- 自分の役割（QA、開発者、マネージャー）に合わせたプロンプトの例を尋ねる
- 以下のいずれかのワークフローに進む
要件から新しいブラウザテストを作成する
mabl MCP を使って、[application name] アプリの新しいブラウザテストを作成したいと考えています。要件は次のとおりです: [検証したい機能またはユーザージャーニーを記述するか、その参照先を指定してください。例: 「Jira 課題 MABL-1234 の受け入れ基準」]。
作成を始める前に、これをエンドツーエンドでどのようにテストするか説明してください。課題やドキュメントから情報を取得する場合は、抽出した基準を先に提示し、確認できるようにしてください。テストオーサリングの選択肢と、最良のテストを作成するために役立つその他の情報も教えてください。
想定される動作: mabl のテストプランニングエージェントが、ユーザーの説明や Jira などの連携ソースをもとに、対話形式でテストの意図とステップを形作ります。プランを確認すると、クラウドまたはローカルの mabl デスクトップアプリでのオーサリングセッションに引き継がれ、作成の様子を確認できるタスク URL が提供されます。
会話の次のステップ:
- オーサリングが始まる前に、抽出された基準やプランを調整する
- オーサリングセッションをクラウド（推奨）またはローカルで開始する
- オーサリングの進捗を確認し、生成されたテストをレビューして編集する
他の MCP と組み合わせる: 要件を記述する代わりに、エージェントにソースから直接読み取らせることもできます。Atlassian/Jira（または Atlassian Rovo）などの課題管理 MCP は課題から受け入れ基準を取得し、Figma などのデザインツール用 MCP は仕様から意図された動作を取得し、Confluence などのドキュメント MCP はページから情報を取得します。mabl 単体ではこれらを読み取れないため、使用したい MCP を指定してください。
テストの要件に対するカバレッジギャップを確認する
[workspace name] ワークスペースにある [test name] テストを、次の要件と比較してください: [要件を貼り付けるか、Jira 課題 ID を参照してください]。カバーされている項目、不足している項目、追加すべき項目を明確にした、構造化されたカバレッジレポートを作成してください。
想定される動作: テストがすでにカバーしている内容、要件で求められているのにテストに不足している内容、そして追加すべき具体的なステップやアサーションを示す、構造化されたレポートが得られます。対象は 1 つの要件に対する 1 つのテストに限定され、ワークスペース全体のスキャンではありません。
会話の次のステップ:
- 不足しているステップをエージェントにテストへ追加させる
- 変更後にカバレッジチェックを再実行する
- 同じ要件に対して 2 つ目のテストを比較する
他の MCP と組み合わせる: 要件を貼り付ける代わりに、課題管理ツール（Atlassian/Jira など）から直接取得することで、常に最新の要件に対して比較を実行できます。
コンプライアンスのために mabl テストを Xray にマッピングする
[workspace name] ワークスペースの mabl テストと、プロジェクト [PROJ] の Xray テストケースを一覧表示してください。各 mabl テストを対応する Xray ケースにマッピングし、まだ mabl の自動テストでカバーされていない Xray ケースを示してください。
想定される動作: エージェントは、mabl テストを対応する Xray ケースに照合し、それらのマッピングを適用し、まだ mabl の自動テストでカバーされていない Xray ケースを明らかにしようとします。これにより、対応に活用できるコンプライアンスギャップのビューが得られます。ワークスペースで Xray 同期インテグレーションが設定されている必要があります。
会話の次のステップ:
- カバーされていない Xray ケースのテストをオーサリングする
- 個々のマッピングを調整または確認する
- 監査用にカバレッジビューをエクスポートする
リリース前にプレビュー URL またはブランチ URL に対してテストを実行する
[test name] テストを、[https://pr-1234.preview.example.com] のプレビューデプロイメントに対してクラウドで実行し、合格するかどうか教えてください。以前の結果を再利用せず、結果を取得し直してください。失敗した場合は、その原因を分析してください。
想定される動作: mabl が、指定したオーバーライド URL に対してテストをクラウドで実行し、合否を報告します。失敗した場合、エージェントが自動的に AI 失敗分析を取得するため、チャットを離れることなく原因を把握できます。
会話の次のステップ:
- 実行の他の設定（ブラウザ、環境、クレデンシャル）をオーバーライドする
- 1 つのテストではなく、プラン全体をプレビュー URL に対して実行する
- 失敗を詳しくトリアージする
他の MCP と組み合わせる: CI/CD MCP によるデプロイステップの後に実行を自動的に開始したり、合否の概要を Slack などのチャット MCP に投稿したりできます。
朝の品質スタンドアップを実行する
[workspace name] ワークスペースについて、5 行のスタンドアップをまとめてください: 現在実行中のもの、過去 24 時間に失敗したもの、新しいリグレッションと思われる失敗と既知の不安定なテストの区別、そして最初に確認すべき 1 点です。
想定される動作: 現在実行中のテスト、過去 24 時間に失敗したテスト、新しいリグレッションと思われる失敗と既知の不安定なテストの区別、そして「まずここを確認」という 1 つの推奨事項をまとめた、読み取り専用のダイジェストが得られます。
会話の次のステップ:
- 「まずここを確認」とされた失敗を深掘りする
- 対象期間を過去 1 週間に広げる
- 特定のプランまたは環境に絞り込む
他の MCP と組み合わせる: Slack などのチャット MCP を使って、毎朝チームのチャンネルにスタンドアップを投稿できます。
エビデンスを使って単一の失敗テストを深掘りする
テスト実行 [ID] が失敗しました。エビデンス付きで失敗分析を実行し、失敗したステップのスクリーンショットと DOM スナップショットを取得して、何が問題だったかをわかりやすく説明してください。原因はアプリ、テスト、環境、それともそれ以外でしたか。
想定される動作: mabl の AI 失敗分析が、概要、根本原因、推奨される次のステップ、そしてアプリのバグ、テストの問題、環境の問題のいずれであるかについてのわかりやすい判定を提供します。
会話の次のステップ:
- 対話形式で分析を続ける: 「API コールがタイムアウトした理由を詳しく調べてください」
- スクリーンショット、ログ、ネットワークデータなど、さらに多くのアーティファクトを取得する
- 提案された修正を適用して再実行する
他の MCP と組み合わせる: 根本原因について合意したら、課題管理 MCP（Atlassian/Jira など）を使って、分析内容と実行へのリンクを添えてバグを起票できます。
PR がオープンな間に失敗したデプロイメントをトリアージする
[workspace name] ワークスペースの最新の mabl デプロイメントが失敗しました。失敗したテストを取得し、それぞれに mabl の AI 失敗分析を実行して、各テストが本当のリグレッションなのか、単に不安定なだけなのかを教えてください。本当のリグレッションについては、現在のブランチの差分を確認し、原因である可能性が最も高いファイルを指摘してください。マージする前に修正したいと考えています。
想定される動作: mabl の AI 失敗分析を使って、エージェントは各失敗が本当のリグレッションなのか、断続的な不安定さによるものなのかを評価します。リポジトリ内でこれを実行すると、エビデンスを現在のブランチの差分と比較し、原因である可能性が最も高いファイルを提案することもできるため、マージ前に修正できます。
会話の次のステップ:
- 環境の問題が除外されたら、デプロイメントを再トリガーする
- 個々の失敗を深掘りする
- 確認されたリグレッションについてバグを起票する
他の MCP と組み合わせる: 失敗がリグレッションによるものである場合、関連ファイルの検索には、リポジトリをチェックアウトしたコーディングエージェントと連携する必要があります。失敗のトリアージ自体は、mabl MCP 単体で機能します。