ソフトウェアテストエージェントと不安定なテストの終焉
Rui Li
どのエンジニアリングチームにも「恥のフォルダー」があります。テストスイートの片隅に、不安定なテストが積み重なっていく場所です。月曜日にはパスして火曜日には失敗するテスト。ローカルではパスしてCIでは失敗するテスト。誰も理由を理解できないまま失敗し、再実行するとまたパスするテスト。
不安定なテストは単なる小さな煩わしさではありません。テスト基盤全体への信頼を蝕む、構造的な問題です。開発者がテスト結果を信頼できなくなると、結果を確認しなくなります。確認しなくなると、テストは形式的なものになります。テストが形式的になると、バグが本番環境に流出します。
皮肉なことに、ほとんどの不安定なテストは作成当初から欠陥があったわけではありません。書かれた時点では、アプリケーションの動作を正確に表していました。アプリケーションが変化し、テストが適応しなかったことで不安定になったのです。先月まで機能していたCSSセレクターが、今月のボタンのリデザインと一致しなくなります。200msでデータを返していたAPIエンドポイントが、データベースの成長により800msかかるようになります。特定の要素順序を前提としていたテストが、ソートアルゴリズムの変更によって壊れます。
これがメンテナンスの問題です。そして、従来の自動テストに限界がある理由でもあります。
従来の自動化が不安定なテストを生む理由
従来のテストスイートにおける不安定さの根本原因はシンプルです：テストは動的なアプリケーションを静的に表現したものに過ぎないからです。
Playwrightのテストは、作成時点におけるUIの特定の状態をキャプチャします。正確なセレクター、正確なタイミングの前提、正確なデータの期待値をコードに埋め込みます。それらのいずれかが変化すると——そしてそれは常に変化します——テストは壊れます。バグがあるからではなく、テストが持つアプリケーションのモデルが古くなっているからです。
チームは「ベストプラクティス」でこれを管理しようとします。CSSセレクターの代わりにdata-testid属性を使う。余裕を持ったタイムアウトを設定する。リトライロジックを使う。こうした対策は助けになりますが、根本的なアーキテクチャ上の問題への応急処置に過ぎません：テストとアプリケーションは独立して進化する別々のシステムであり、それらを同期させることは誰の仕事でもないのです。
実際には、テストのメンテナンスがすべての機能開発にコストとしてのしかかります。UIのリデザインをリリース？壊れたテストの更新に2日間を見込んでください。コンポーネントをリファクタリング？E2Eスイートの半分が赤くなります。こうしたサイクルを繰り返すうちに、チームはテストを修正するのではなく削除し始めます。カバレッジは低下し、信頼は落ち、恥のフォルダーは膨らみ続けます。
ソフトウェアテストエージェントが不安定さを根本から排除する方法
ソフトウェアテストエージェントは、テストをまったく維持しないという異なるアプローチで問題に向き合います。テストを再生成するのです。
TestSpriteがアプリケーションに対して実行される際、記録されたアクションを再生するわけではありません。コードベースと製品要件を読み込み、アプリケーションの現在の状態を理解し、今この瞬間の現実を反映した新鮮なテスト計画を生成します。セレクターはテスト時に生成されるため、古いセレクターは存在しません。エージェントは実際のアプリケーション動作を観察するため、タイミングの前提もありません。エージェントは遭遇したデータ状態に適応するため、データへの依存もありません。
これは従来の意味での「自己修復」ではありません——ツールが壊れたロケーターを検出して新しいものを推測しようとするような。自己修復は、根本的に脆弱なアーキテクチャに対する修復戦略です。再生成は脆弱さそのものを完全に排除します。テストスイートは常に最新の状態です。なぜなら、常に新しく生成されるからです。
実際の効果として、開発者はテストのメンテナンスについて一切考えなくて済むようになります。リデザイン後にロケーターを更新する必要はありません。バックエンドの変更後にタイムアウトを調整する必要もありません。要素のレンダリング順序によって引き起こされる謎のCI失敗をデバッグする必要もありません。エージェントがすべてを処理します。
信頼の方程式が変わる
テストが不安定でなくなれば、開発者はテストを信頼します。
開発者がテストを信頼すれば、実際に結果を確認します。結果を確認すれば、失敗を修正します。失敗を修正すれば、バグは本番環境に流出しません。
これは好循環であり、ノイズを排除することから始まります。結果の3%がランダムな失敗であるテストスイートは、開発者が失敗を無視するよう訓練するテストスイートです。すべての失敗が実際のバグを表すテストスイートは、品質を向上させるテストスイートです。
TestSpriteのアプローチ——メンテナンスではなく再生成、コード記録ではなく仕様駆動の生成——は、偽陽性がほぼゼロのテストスイートを生み出します。テストが失敗するとき、それは実際に何かが間違っていることを意味します。このシグナルの明確さが、チームとテスト基盤との関わり方を変えます。
QAテストツールからQAテストエージェントへ
ソフトウェアテストにおけるツールからエージェントへの転換は、根本的にテストライフサイクルの所有権の問題です。
テストツールを使う場合、所有するのは開発者です。テストを書き、メンテナンスし、デバッグし、いつ実行するかを決めます。ツールは人間の努力を増幅させるものです。
ソフトウェアテストエージェントを使う場合、所有するのはエージェントです。生成、メンテナンス、実行、診断をエージェントが担います。開発者が所有するのは正しさの定義——製品がどうあるべきか——と結果のレビューです。それ以外はすべて委任されます。
この委任こそが、不安定なテストを時代遅れにするものです。不安定なテストが存在するのは、急速に変化するアプリケーションに合わせて大規模なテストスイートを人間がメンテナンスし続けることができないからです。メンテナンスループから人間を取り除けば、不安定さは消えます。
自律型テストエージェントは、すべてのプルリクエストに対して5分以内にフルテストスイートを実行します。GitHubインテグレーションが不正なマージをブロックします。ビジュアルテスト編集により、コードを書かずに意図を調整できます。
「恥のフォルダ」をついに空にできる。