どのチームにも、自社のアプリケーションに固有の失敗パターンがあります。たとえば、ログインの失敗、データの問題、状態が正しくないテストアカウントなどです。これまでは、こうした失敗を mabl のデフォルトのテスト失敗の理由のいずれかに当てはめる必要があり、期限切れのクレデンシャルのような具体的な問題が、「環境の問題」のような大まかなくくりに埋もれてしまっていました。今後は、チームが実際に失敗をどう捉えているかに合わせて、独自のカスタムのテスト失敗の理由を作成できます。
カスタムのテスト失敗の理由を使うと、次のことが簡単になります。
- パターンの特定: 期限切れのクレデンシャル、不安定なステージングサーバー、サードパーティの障害などをひとまとめにするのではなく、それぞれを区別できます。
- ノイズの排除: 既知の想定内の失敗を、対応が必要なリグレッションと切り分けることで、成功率がゆがめられるのを防ぎます。
- 自社の言葉でレポート: 関係者がすでに理解している用語を使って、失敗の傾向を追跡できます。
試してみる
1つのワークスペースには、最大50個のカスタムのテスト失敗の理由を設定できます。ワークスペースの所有者は、mabl アプリの テスト環境設定 > テスト失敗の理由 でこれらを管理できます。
- 新しいカスタムのテスト失敗の理由を作成する - 表示名、チームに背景情報を提供する任意の説明、そして高度なAIが有効な場合は、mabl エージェントにその理由をいつ自動で割り当てるかを伝えるエージェントガイドラインを追加します。効果的なガイドラインの書き方については、カスタムのテスト失敗の理由のためのエージェントガイドラインを作成するをご覧ください。
- テスト失敗の理由の名前を変更する - 表示名はいつでも変更でき、過去の参照も自動的に更新されます。
- テスト失敗の理由を無効にする - 特定のテスト失敗の理由の使用をやめたい場合は、それを無効にすると、すでにその理由で分類されたデータは保持したまま、テスト失敗の理由の選択リストから非表示にできます。
mabl のデフォルトのテスト失敗の理由は引き続き利用でき、名前の変更や削除はできません。
カバレッジダッシュボードに表示された、デフォルトとカスタムのテスト失敗の理由の組み合わせ
テストにカスタムのテスト失敗の理由が割り当てられると、そのデータは、失敗データがすでに存在するあらゆる場所で利用できます。具体的には、結果ページ、カバレッジ概要ダッシュボードのグラフ、CSV エクスポート、mabl API のテスト実行の概要、および _run_categorization BigQuery エクスポートテーブルなどです。
詳細情報
失敗の分類の詳細については、テスト失敗の理由をご覧ください。