UIテスト自動化とメンテナンス比率

UIテスト自動化の比率を下げる要因

セレクターと待機処理は、バグではない失敗を生み出します。そうした失敗が 1 件起きるたびに、次の赤いビルドを確認しようというチームの意欲が少しずつ削られていきます。

テストスイートが死ぬ瞬間

その瞬間は、振り返ってみればたいてい特定できます。誰かが「とりあえず再実行すればいい」と言い、そしてその判断が正しかった週です。それ以降、あらゆる失敗に対して再実行が最初の対応になり、本物のリグレッションも、運よく通るまで再実行されるか、隔離されるかのどちらかになります。

テストスイートを信頼しないと誰かが決めるわけではありません。信頼は少しずつ失われていくのです。

比率を守る

• 新しいテストを追加する前に、不安定なテストを修正します。 歓迎されない方針ですが、正しい方針です。誰も見ないテストスイートに新しいテストを追加しても、価値はありません。

• 隔離は、こっそりではなく、はっきりと目立つ形で行います。 スキップしたテストは可視化し、担当者を割り当てるべきです。そうしなければ、スキップリストはテストの墓場になります。

• 再実行を 1 つの発見として扱います。 テストに再実行が必要だったのなら、テストか環境のどちらかに問題があります。そのまま先に進まず、記録に残してください。

構造的な部分

規律によって、セレクターと待機の問題には対処できます。しかし 3 つ目のコストには対処できません。カバレッジは人が書ける量に制限される一方で、プロダクトはそれを上回る速度で成長します。コードの多くがコーディングエージェントから届く場合はなおさらです。

DOM をたどるパスではなく意図としてステップを表現すれば、セレクター起因の失敗の大部分がそもそも発生しなくなります。これは比率を左右する単一の要因として最大のものです。

ローカルに何もインストールしたくない場合は、同じセットアップを TestSprite のダッシュボードからも行えます。CLI のその他の機能について詳しくは、 CLI リポジトリ。

悪化した比率を取り戻す

調査ではなく再実行が当たり前になっているテストスイートでは、これから規律を持ち込むだけでは解決しません。既存のノイズがその習慣を強化し続けるからです。立て直すには、意図的なリセットが必要です。

直近 50 件の失敗を取り上げ、それぞれを本物・セレクター・タイミング・環境のいずれかに分類します。この 1 時間の作業で、3 つのコストのうち実際に抱えているものが分かります。原因は分散しているのではなく、1 つに集中しているのが普通です。失敗するたびに個別のテストを直すのではなく、そのカテゴリをテストスイート全体にわたって修正してください。

そのうえで、まだ失敗しているものは担当者と期日を付けてすべて隔離し、残ったテストスイートをグリーンの状態にします。信頼されている小さなグリーンのテストスイートは、無視することが習慣になった大きな赤いテストスイートよりも価値があります。そして比率を改善できるのは、この状態からだけです。

失敗のコストが最も低い場所で実行する

プルリクエストごとに実行します。そうすれば、失敗が指し示すのは 1 週間分の変更ではなく、1 つの変更になります。

• GitHub App は、TestSprite のダッシュボードで設定する webhook です。パイプラインがすでに発行しているデプロイイベントを監視するため、リポジトリ内は何も変わりません。

• GitHub Actions は、ターミナルから設定し、このステップを自分のワークフローの中に組み込みます。

TestSprite が比率を守る仕組み

偽の失敗の最大の発生源を取り除くという、直接的な方法です。ステップはロケーターではなく意図として表現されるため、セレクターの破損の大半を生んでいる見た目上の変更が、赤いビルドにつながりません。待機処理はテストごとの調整作業ではなく、自動的に処理されます。これで残りの大部分も解消されます。

カバレッジはプロダクトから生成され、自然言語で調整できます。そのため、テストスイートを広げてもメンテナンスが比例して増えることはありません。この比例関係こそ、通常はカバレッジと信頼のどちらかを選ばせる原因になっているものです。

その結果として得られるのは、失敗が起きたら驚くようなテストスイートです。人が再実行ではなく調査を行うのはこの状態であり、テストスイート全体が気づかないうちに飾りになってしまうことなくカバレッジを伸ばし続けられるのも、この状態だけです。