注文が正常に作成されたことを確認するテストを想像してみてください。新しい注文は作成されましたが、ページネーションされたリストの2ページ目に表示されています。注文が作成されなかったわけではなく、注文一覧の1ページ目に表示されていなかったためにテストが失敗します。そのため、実際には存在しない問題のトラブルシューティングにチームの時間を費やすことになります。
その経験がテストスイート全体に及ぶと、実際にテストしている内容とは無関係な失敗のトリアージに何時間も費やすことになります。
エージェント型実行時リカバリにより、mablはこの状況を自動的に処理します。テストステップが実行中に失敗した場合、mablはエージェントを起動して失敗を分析し、テストが失敗としてマークされる前にリカバリを試みることができます。たとえば、新しく作成した注文が2ページ目に表示された場合、実行時リカバリは自動的に次のページに移動して新しい注文を見つけます。
早期アクセス
実行時リカバリはアーリーアクセスでご利用いただけます。実行時リカバリを有効にするには、ワークスペースの所有者が Labs ページで次の設定を有効にしてください: ワークスペース > Labs
- mabl エージェントでプレビュー AI モデルを使用する - プレビューモデルのデータ処理場所が米国内であることは保証されません。
- 実行時リカバリ - この設定は、ワークスペースでmablエージェントのプレビューモデルが有効になっている場合にのみ使用できます。
ユースケース
実行時リカバリは、手動テスターが自然に回避するような一般的な障害を処理します。例として以下が挙げられます：
- 予期しないモーダルを閉じる
- 古い検索フィルターのクリア
- ページ分割されたリストの別のページへの移動
- 最初のクリックで反応しなかったボタンを再試行する
偶発的な失敗から回復することで、テスト結果は重要なことに集中できます。つまり、アプリケーションの実際のバグや本物のリグレッションです。
仕組み
ステップが失敗し、自動修復で高い信頼度の一致が見つからない場合、実行時リカバリが介入します。
- 失敗を分析する - mablエージェントは、過去の成功および失敗したクラウド実行のコンテキストを使用して失敗を分析し、成功した実行のスクリーンショットとステップの結果を比較して、何が変わったかを把握します。
- アクションを決定する - このコンテキストに基づいて、エージェントはどの修正アクションを実行するかを決定します。
- 次のステップに進む - 回復が成功した場合、エージェントはテストに制御を戻します。回復が成功しなかった場合、テストは失敗し、何が失敗したか、エージェントが試みたこと、および結果についての詳細な説明が表示されます。
重要な点として、エージェントはリカバリーを試みる価値があるかどうかを判断する際に、テストの目的をコンテキストとして使用します。エージェントがその失敗をテストで検証している内容の核心と認識した場合、リカバリーは試みられません。
近日公開予定
デフォルトでは、実行時リカバリはステップを失敗としてマークし、実行を継続し、最終的にテストを失敗させます。今後数週間以内に、プランレベルで実行時リカバリの設定を構成できる機能を追加する予定です。
フィードバックを共有する
実行時リカバリがお客様の作業をより簡単にすることを目指しています。早期アクセス期間中にフィードバックがあれば、ぜひmablのカスタマーサクセスマネージャー（CSM）にお知らせください。お客様のインサイトが、より良いプロダクトの構築に役立ちます！
詳細を見る
エージェントの実行時リカバリの仕組みについて詳しくは、ドキュメントをご覧ください。