UI自動化ツールの3つのカテゴリ
コードフレームワーク。 実際のプログラミング言語でテストを書きます。 前提： テストを書き、保守する時間のあるエンジニアがいること。
記録型・ローコード型。 担当者がエディタ上でフローを組み立てます。 前提： テストフローを組み立てることが業務である人がいること。
エージェント型。 カバレッジは自動生成され、自然言語で調整されます。 前提： 自分が書いたのではないカバレッジをレビューすること。
最も崩れやすい前提はどれか
2つ目です。ローコード型のプラットフォームは、テストを担う専任の職能があることを前提に設計されていますが、その職能をすでに持たないチームは少なくありません。プラットフォーム自体に問題はなく、ライセンス料も支払われていますが、フローを書く人がいません。そのため、最後のテスターが去った月を最後に、カバレッジは増えなくなります。
1つ目の前提は、もっとゆっくり崩れます。エンジニアはテストを書けますが、その作業は機能のリリースと時間を奪い合います。その結果、テストスイートは最初の四半期に成長し、そこで止まります。
機能比較表より役に立つ質問
200番目のテストを書くのは誰ですか。 最初の10件は評価期間中に書かれます。問うべきは6か月目の姿です。
UIがリデザインされたら何が起きますか。 ここが継続的に発生するコストであり、答えはカテゴリによって大きく異なります。
失敗は、それを修正する人の目にどう見えますか。 その修正者がコーディングエージェントであるケースは増えており、エージェントはスクリーンショットを解釈できません。
アサーションまで到達しなかった実行は、合格として報告されますか。 意識して確かめる価値があります。答えが「はい」になることもあるためです。
比較表に現れないコスト
ここで挙げたどのカテゴリにも、ベンダーが数値化しない継続的なコストがあります。ベンダー側ではなく利用側の事情で決まるコスト、すなわち「何をカバーするかを決めるコスト」です。
コードフレームワークでは、誰かがテストを書きます。つまり、そのテストが必要だと誰かが先に判断しています。ローコードのエディタでも同じです。生成されたカバレッジの場合、この判断はプランのレビューへと移ります。レビューのほうが速く済みますが、コストがゼロになるわけではなく、しばしば省略され、「誰も読んでいないカバレッジ」という失敗パターンを生みます。
どれを選ぶ場合でも、このコストを明示的に見込んでおいてください。誰かが週に1時間、何がカバーされ何がカバーされていないかを確認する。それが、自社プロダクトを映したテストスイートと、18か月前に自動化しやすかったものを映しただけのテストスイートとの違いになります。
評価の進め方
意図的に壊してみてください。保存しても値が残らなくなるといった実際のリグレッションを仕込み、各候補が何を報告するかを観察します。テストが失敗するか、失敗の内容がどこで食い違ったかを示しているか、そしてその出力から修正する人が作業を始められるか。この1つの試行は、1か月分の機能比較よりも多くのことを教えてくれます。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
何もインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドラインでできるそれ以外の操作をすべてまとめているのは、こちらの CLIリポジトリ。
方法は2つあり、選択のポイントは実のところ、パイプラインを誰が所有しているかです。ダッシュボードから GitHub App を接続する方法なら、リポジトリへの変更は一切必要ありません。すでにビルドが発行しているデプロイに反応して動くためです。一方、 GitHub Actions のステップを追加する方法では、チェックがリポジトリ内に置かれ、ビルドの他の部分と同じようにレビューの対象になります。
TestSpriteが置いている前提
自分で書いたのではないカバレッジをレビューする、という前提です。これがトレードオフです。テストを書く担当者は不要になり、その代わりに誰かがプランを読んで修正します。
具体的には、テストケースは実際のプロダクトから生成され、ステップは意図として表現されるためリデザインを経ても機能し続けます。そして失敗は、何を試みたか、アプリが何をしたか、どこで両者が食い違ったかという形で返り、人と同じようにコーディングエージェントもそれをもとに対処できます。
テスト専任の職能を持たないチームにとって、この前提は他の2つよりも満たしやすいものです。プランのレビューに必要なのは週1時間ですが、テストスイートを書き上げるには専任のポジションが必要になるからです。そのポジションが実際にあるなら、コードフレームワークのほうが適しているかもしれません。誠実な選び方は、自分たちのチームが1年後に実際に満たせる前提はどれかを問うことです。
カテゴリを組み合わせてもよいのでしょうか。
問題ありません。実際、多くのチームが最終的にそうしています。意図して仕様化したフローはコードフレームワークで、広い範囲のカバレッジは生成で、という分担がよく見られます。
オープンソースで十分ですか。
多くの場合は十分です。そもそもコストはライセンスではありませんでした。コストはテストの作成と保守であり、そこはオープンソースでも変わりません。
記録と再生はどうでしょうか。
作るのは速く、保守は高くつきます。記録が捉えているのは意図ではなく経路だからです。単発の再現には役立ちます。
評価にはどのくらいの期間をかけるべきですか。
リデザインか実際のリグレッションを1度は含む程度の期間です。どちらも起きないトライアルでは、肝心な部分を確かめられていません。
最もよくある失敗は何ですか。
こうであってほしいチーム像に合わせて選んでしまうことです。6か月後にこれを保守しているチームに合わせて選んでください。