AIテストエージェントをCI/CDパイプラインに統合する方法
Rui Li
多くのエンジニアリングチームはCIを導入しています。同時に、デプロイをブロックし始めた瞬間に無効化・無視された、低速で不安定なエンドツーエンドテストの「墓場」も抱えています。
問題はCI/CDにあるのではありません。テスト自体にあります。製品の見た目が変わる前に書かれ、その後適切にメンテナンスされていない脆弱なスクリプトが原因です。AIテストエージェントを導入することで、不安定さの問題を解決するだけでなく、CIパイプラインそのものが持つ可能性を根本から変えることができます。
従来のCIテストセットアップで何が壊れるか
CI上の従来の自動テストスイートには、3つの慢性的な障害モードがあります。
不安定さ。ローカルでは通過するのにCI上では失敗するテスト——コードとは無関係なタイミングの問題、環境の差異、古くなったセレクターが原因です。エンジニアはそれらを無視することを覚えます。エンジニアに無視されるテストスイートは、セーフティネットとして機能しません。
メンテナンスの遅延。UIはテストスクリプトの更新よりも速く変化します。ボタンのデザイン変更、クラス名の変更、フォームの構造変更——これらのいずれもが、多数のテストを同時に壊す可能性があります。メンテナンスコストはテストカバレッジとともに増大するため、テストを増やすインセンティブが失われます。
カバレッジのギャップ。テストの作成には時間がかかります。スプリントのプレッシャーを受けたエンジニアはエッジケースを省略し、目立たないフローを後回しにし、「後でテストを追加する」と約束します。その「後で」は永遠に来ません。テストしている対象が製品全体のほんの一部であるため、CIスイートは速く実行されます。
AIエージェントは、症状レベルではなくアーキテクチャレベルでこれら3つすべてに対処します。
AIテストエージェントとCIの統合方法
統合レベルでは、TestSpriteのようなAIテストエージェントは、他のテストランナーと同様にCIパイプラインに接続します——GitHub Actionsワークフロー、GitLab CIジョブ、CircleCIステップ、またはデプロイパイプラインからのWebhookを介して行います。仕組みのセットアップは数分で完了します。
異なるのは、実行中に何が起きるかです。
固定セレクターに対して固定スクリプトを実行する代わりに、エージェントはテストの説明から導き出されたインテントベースのロケーターを使用してアプリケーションをナビゲートします。テスト作成後にDOMが変更されていても、エージェントはCSSパスではなく、要素のロールとコンテキストに基づいて正しい要素を特定します。クラス名が変わってもテストは壊れません。
テストが失敗した場合、エージェントは障害を分類し、製品の動作における実際のリグレッションと、ネットワークタイムアウトやテストフィクスチャの欠落といった環境レベルの問題を区別します。エンジニアリングチームは、実際のバグではないCI障害の調査に時間を費やすことがなくなります。
パイプラインの適切なポイントでテストをトリガーする
適切に設定されたAIテストパイプラインは、トリガーポイントごとに異なるテストスコープを実行します。
プルリクエストごとに、変更されたコードによって影響を受ける可能性が最も高いフローをカバーする、絞り込まれたスイートを実行します。TestSpriteはdiffを分析し、それに応じてテストの実行を優先順位付けできます。これにより、コミットのたびに全回帰スイートを実行することなく、エンジニアは迅速かつ関連性の高いフィードバックを得られます。
mainへのマージ時には、全回帰スイートを実行します。これはコードがステージングまたは本番環境に到達する前の最終ゲートです。包括的であり、かつ高速でなければなりません——複数のエージェントによる並列テスト実行により、500件のテストスイートを45分から8分未満に短縮できます。
本番環境へのデプロイ時には、ライブ環境に対してスモークスイートを実行します。これらのテストはデプロイが成功し、重要なユーザーフローが機能していることを検証します。2分以内に完了し、何かが失敗した場合はオンコールのエンジニアに通知します。
やめられること
CIにAIテストエージェントを導入することで得られる、あまり目立たないメリットは、消えていく作業です。
UIが変わるたびにセレクターマップをメンテナンスすることはなくなります。リグレッションではなくフレークによるCI障害のトリアージも不要になります。フィーチャーが安定する前に新機能のテストスキャフォールドを作成することもなくなります。失敗しているテストを無効にするか書き直すかという議論も不要になります。
パイプラインは動作し、テストは通過するか実際の問題を明らかにするかのどちらかです。エンジニアは必要なフィードバックを得て、次に進むことができます。
最初から正しく統合する
デプロイパイプラインの最終ゲート——本番環境の前に実行されるステップから始めましょう。まずそこでAI駆動のテストを安定して通過させることに集中してください。チームがテスト結果に意味があると確信できたら、パイプラインを遡って展開していきます——ステージングのデプロイ、次にPRチェックへと広げていきます。
初期段階では、カバレッジの広さよりもシグナル対ノイズ比が重要です。誰も調査する時間がない理由で30%の確率で失敗する200件のテストを持つCIパイプラインより、信頼性の高いAI駆動テストが20件あるパイプラインの方が価値があります。