UIテストツールの確認ポイント1：デザイン刷新で何が起きるか
これはあらゆるブラウザテストスイートに繰り返し発生するコストであり、その答えはツールによって大きく異なります。ステップが DOM 上のパスとして表現されているツールは、見た目だけの変更でも失敗します。ステップが意図を表現しているツールは、ほとんどの場合そうなりません。
この点は、言葉で説明してもらうのではなく、実際に動かして見せてもらうようベンダーに依頼してください。
確認ポイント2：200番目のテストを誰が書くのか
最初の10件は、評価期間中に意欲のある担当者が書きます。半年後、新しい画面が40増え、当初の推進者が異動していれば、正直な答えは「誰も書かない」であることがほとんどです。放置されたテストスイートの多くは、技術的な理由ではなく、この段階で見捨てられています。
確認ポイント3：修正する側から見て、失敗はどう見えるか
スクリーンショットとスタックトレースは、人間が解釈することを前提としています。しかし、修正を担うのはコーディングエージェントであることが増えており、エージェントにはそれができません。何を試み、アプリケーションが実際にどう振る舞い、どこで両者が食い違ったのかを示す失敗であれば、人間でもエージェントでもそのまま対応できます。
確認ポイント4：アサーションに到達しなかった実行が合格として報告されないか
これはトライアル中に意図的に試してください。答えが「報告される」になることも実際にあり、その場合は他のすべてが無意味になるからです。何もアサーションしないままタイムアウトした実行をグリーンとして報告するスイートは、スイートがない状態よりも悪いものです。情報ではなく安心感を生み出すからです。
試す価値のある演習
実際に動いているものをわざと壊してみてください。保存しても値が残らないようにする、フィルターが黙ってすべてを返すようにする、といった具合です。そのうえで、候補となる各ツールを観察します。テストは失敗するか。その失敗は、実際にどこが食い違ったのかを言い当てているか。修正する人はその出力から着手できるか。半日あれば、1か月分の比較よりも多くのことがわかります。
失敗について具体的に確認すべきこと
どのベンダーも、テストが成功する実行は見せてくれます。デモで本当に価値のある5分間は、失敗する実行を見せてもらう時間です。見るべき点は3つあります。
出力は期待されていた挙動まで示しているか、それとも実際に起きたことだけか。壊れたページのスクリーンショットを見せるだけで、本来どうあるべきだったかを示さないレポートは、解釈をこちらに委ねています。
動画を見なくても、フローのどこで失敗したのか分かるか。動画は補助としては優れていますが、主たる情報源としては不向きです。2分の録画を早送りしてその瞬間を探す作業こそ、まさに避けたかった手間だからです。
そして、エージェントがその出力をもとに動けるか。バグを直すのが人ではないケースが増えており、この変化は、優れた失敗レポートの条件をこの10年のどの出来事よりも大きく変えています。
どのツールにも付いて回るコスト
セレクター
機能的には何も変わらないデザイン刷新でも、スイートが赤くなります。
メンテナンス時間の大半が実際に費やされる場所です。
待機処理
固定の待ち時間は遅いうえに、それでも不安定です。正しい待機には、何を待つのかを把握している必要があります。
不安定なテストの多くは、ここに原因があります。
人が書いたカバレッジ
カバーできるのは誰かが書いた範囲であり、それは壊れやすいフローではなく、関心を持たれたフローです。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルに何もインストールしたくない場合は、TestSprite のダッシュボードでも同じセットアップを行えます。CLI のその他の機能は CLI リポジトリにあります。
パイプラインが別のチームの管理下にある場合は、 GitHub App が最も抵抗の少ない方法です。webhook であるためリポジトリには何の変更も加えず、ビルドが新しいバージョンの公開を通知した時点で実行されます。代わりにチェックをリポジトリ上で見えるようにしたい場合は、 GitHub Actions のステップでそれが可能です。
TestSprite は4つの確認ポイントにどう答えるか
デザイン刷新の場面では、意図として表現されたステップは見た目の変更に影響されないため、ボタンが移動しただけでスイートが赤くなることはありません。200番目のテストは人が書くのではなく、製品そのものから生成され、平易な言葉で調整されます。失敗時には、何を試み、アプリケーションが実際にどう振る舞い、どこで両者が食い違ったのかが示されるため、人だけでなくコーディングエージェントもそのまま利用できます。そして、アサーションに到達しなかった実行が合格として報告されることはありません。
4つ目は、どのトライアルでも自分で試してみる価値があります。もちろん TestSprite でも同様です。保存しても値が残らないように壊してみて、チェックが赤くなることを確認してください。
得られるのは、テストを書くよりも速くリリースするチームに追随できるカバレッジと、ほとんどが本物であるために読まれ続ける失敗シグナルです。
ブラウザ対応は重要ですか？
まずは自社のアナリティクスを確認してください。多くのチームは、ユーザーがほとんど使っていないブラウザのカバレッジに費用を払っています。
オープンソースと商用のどちらを選ぶべきですか？
コストになるのはライセンスではありません。コストはテストの作成とメンテナンスであり、それはどちらを選んでもさほど変わりません。
後から移行できますか？
テストは移植できないものと考えてください。乗り換えを前提にするのではなく、1年後にどうなっていたいかを基準に選んでください。
トライアルはどのくらいの期間が必要ですか？
デザイン刷新か実際のリグレッションを1回は含められる長さが必要です。どちらもなければ、評価したのはデモにすぎません。
複数のツールが必要な場合はどうすればよいですか？
よくあることですし、問題ありません。意図的に作り込んだフローはコードベースのフレームワークで、幅広い範囲は生成されたカバレッジで押さえるという構成は一般的です。