結論から
-
Seleniumを選ぶべきなのは 精密な制御や、特殊なブラウザ・プラットフォームへの対応が必要な場合、あるいはすでにWebDriverを前提に構築されたエコシステムの中で作業している場合です。
-
TestSpriteを選ぶべきなのは 何をテストするかを決めることと、テストスイートを生きた状態に保つことがボトルネックになっている場合です。コーディングエージェントから届くコードが多くを占めるなら、なおさらです。
-
両方を併用すべきなのは チームが信頼しているSeleniumのスイートがある場合です。それはそのまま残し、誰も書く時間がない範囲をカバーするために、エージェントによる検証を追加します。
項目別の比較
| 観点 | Selenium | TestSprite |
|---|---|---|
| どういうものか | 多くの言語のバインディングを備えた、ブラウザ自動化の標準 | 稼働中のアプリに対してテストを計画・実行し、結果を切り分けるエージェント |
| テストを書くのは誰か | 自社のエンジニア。Java、Python、C#、JavaScriptなどで記述 | 手元のソースから生成し、自然言語で調整 |
| ステップの制御 | 完全。あらゆる操作を自分で指定 | ステップは意図として表現されるため、精密さと引き換えに壊れにくさを得る |
| UIが変わったとき | ロケーターが壊れ、誰かが直すことになる | 見た目だけの変更なら、多くの場合そのまま通る |
| 対応ブラウザ・プラットフォームの広さ | レガシーな対象も含め、業界で最も広い | デプロイ済みのアプリに対する、モダンブラウザでのフロー |
| 継続的なコスト | 作成とメンテナンス。スイートの拡大に応じて増える | レビューと調整。増え方はより緩やか |
| 弱いところ | 広さ。誰かが書いた範囲しかカバーできない | 個々の操作をきめ細かく制御すること |
Seleniumが今も正解である場面
特殊な対応範囲が求められる場合。 古いブラウザ、特定のドライバー挙動、組み込み環境。この対応範囲に並ぶものは他にありません。
決定的な手順が求められる場合。 操作の正確な順序が取り決めの一部であり、決してぶれてはならないときです。
すでにグリッドがある場合。 何年もかけて積み上げたインフラ、スキル、運用の作法は、レガシーという問題ではなく資産です。
このモデルが限界を迎えるところ
限界は単純な算数の問題です。テストはすべて人が書くものであり、人数は固定されている一方で、機能の数はそうではありません。まず2つの兆候が現れます。カバレッジが、壊れやすいフローではなく書いていて面白かったフローに偏ること。そして、各スプリントに占めるメンテナンスの割合が上がり続け、やがて誰かが不安定なテストを削除しようと提案するに至ることです。
移行に実際にかかるコスト
Seleniumからの移行を決めたチームはたいてい、一方を過小評価し、もう一方を過大評価します。
過小評価されるのはグリッドです。グリッドは単なるインフラではなく、すべてのテストに焼き付いた前提の集合です。そのレイテンシに合わせたタイムアウト、その処理能力に合わせた並列度、そのストレージに合わせたスクリーンショットの扱い。こうした前提は移植できず、しかも別の環境で最初に実行するまで目に見えません。
過大評価されるのはテストそのものです。たいていのスイートには、実際に頼りにされている20〜30本のフローという中核と、1年間誰も見ていないロングテールがあります。中核の移行は1週間で終わります。時間がかかるのはロングテールを捨てると決めることで、そこには3回の会議が必要になります。そして、たいていはそれが正しい判断です。
だからこそ、移行するよりも並行して動かすほうが優れています。どのフローが本当に支えになっていたのかは、どれが静かになったときに誰かが気づくかを見ればわかります。
両方を動かす
そのテストを存在させると決めたのが誰かで切り分けます。意図して仕様化したフローはSeleniumに残します。広範なリグレッションと、コーディングエージェントから届いた変更の検証はエージェントに任せます。両者は互いを知らないまま、同じパイプラインから実行されます。
評価するなら、意図的に壊してみる
保存ボタンを押してもデータが残らない、といった実際のリグレッションを仕込み、それぞれのツールが何を報告するかを見てください。問いは3つです。失敗として検出されるか。その失敗は、実際に何がずれたのかを言い当てているか。そして、修正にあたる人やエージェントが、経緯を一から辿り直すことなく、その出力を出発点にできるか。アサーションに到達すらしていない実行を成功と報告するツールは、唯一重要なテストに落第しています。
導入経路は2つあり、選択は実質的に、パイプラインを誰が所有しているかで決まります。ダッシュボードから GitHub App を接続する方法なら、リポジトリに一切変更を加える必要がありません。ビルドがすでに出力しているデプロイに反応するためです。一方、 GitHub Actions にステップを追加する方法では、チェックがリポジトリの中に置かれ、ビルドの他の部分と同じようにレビューされます。最新のコマンドはこちらにあります： CLIリポジトリ。
Seleniumを使っている組織にTestSpriteが加えるもの
テストを書く時間を消費しないカバレッジです。テストケースは製品そのものから生成され、平易な言葉で調整できるため、カバレッジの広さが、テスト作成に割けるエンジニアの人数で決まらなくなります。
日々の運用では、さらに2つの違いが表れます。1つは、ステップがロケーターではなく意図として表現されるため、機能的に何も変えないデザイン変更でスイートが赤くならないことです。これはメンテナンス要因の最大のものを取り除きます。もう1つは、失敗が、何を試み、アプリが何を返し、どこでそれらが食い違ったのかという説明として返ってくることです。この出力は、人だけでなくコーディングエージェントもそのまま利用できます。
既存のグリッドとテストスイートは、そのままの形で残ります。実際の効果として、誰も自動化する時間がなかったフローがカバーされ、チームが意図して書いたテストは引き続き自分たちの管理下に置かれます。
Seleniumはもう時代遅れですか？
いいえ。Seleniumは業界の大部分を支える基盤レイヤーであり、利用できる中で最も広いプラットフォーム対応を今も備えています。圧力がかかっているのは能力ではなく、こなせる量のほうです。
移行しなければならないのでしょうか？
いいえ。全面的な移行が得になることはほとんどありません。すでに機能しているものを動かすのではなく、別のレイヤーでカバレッジを足してください。
Seleniumの不安定なテストはどうすればよいですか？
不安定さの多くは、ロケーターの脆さか、タイミングに関する前提に起因します。意図ベースのステップは前者の大部分を取り除きます。ただし、本当に不安定な環境そのものは、どちらの方式でも解決できません。
TestSpriteは、自分たちのグリッドで実行できるコードを書き出せますか？
生成されたテストのソースは、表示することもファイルに書き出すこともできます。ただしそれは、手作業で保守する成果物ではなく、ある1つの経路のスナップショットとして扱ってください。
どちらが安く済みますか？
総コストで比較してください。Selenium自体は無料ですが、スイートを書いて保守するエンジニアの時間は無料ではありません。答えは、その余力があるかどうかでほぼ決まります。