Autosana

Autosana の中心は、同僚に説明するようにテストを書けることだ。「ログインボタンをタップしてテスト用メールを入力」と打てば、エージェントが手順を自分で組み立てる。XPath も CSS セレクタも保守する必要がない。これが自動化を壊す最大の原因だった。リニューアル後にスイートが死ぬのを見たことのあるチームにとって、違いは指示が意図を語ることにある。レイアウト上の特定の要素ではない。

UI が変わると、エージェントは即座に失敗するのではなくフローを適応させる。Autosana によればエージェントはコードの差分に基づいてテストを更新するため、ボタンが動いても画面名が変わっても、スクリプトを手で直す作業は残らない。これは速く動くチームにとって実に重い意味を持つ。CI のスイートはリニューアルをまたいで動き続け、保守に使う時間も減る。製品がこれを軸に作られており、古い E2E ツールとの分かれ目でもある。

Autosana はモバイルアプリと Web サイトを同じ基盤で扱う。フローは iOS、Android、Web ブラウザで、ローカルでもセットアップ不要のクラウド端末でも実行できる。Flutter、React Native、Swift、Kotlin、React、Ionic といった主要フレームワークに対応する。複数の環境に公開するチームにとって、フローを一か所で書いてどこでも確認できることは、別々のテスト基盤を抱えずに済むということだ。

実行はすべて記録され公開されるので、合格か不合格の一行を信じるのではなく、エージェントが何をしたかを自分の目で見られる。スクリーンショットが各ステップを示すため、再現せずに失敗を診断しやすい。CI でテストが落ちて誰も見ていなかったとき、アプリが壊れたのかテストが壊れたのかを教えてくれるのは多くの場合このリプレイだ。小さな機能だが、やり取りをかなり減らせる。

トリガーでフローをスケジュールしたり、パイプラインに組み込んだりして、レポートをプルリクエスト、メール、Slack で受け取れる。変更が入った瞬間に、後から誰かが見るダッシュボードではなく、必要な人の前にテストが届く。すでに CI を回しているチームにとっての価値は、公開前にリグレッションを捕まえられることだ。Autosana はバックエンド呼び出しでテストを準備できるとも言及しており、フローが自分でデータを用意できる。

バージョン管理を好むチームは、フローをリポジトリ内のファイルとして持ち、GitHub 経由で同期できる。テストが対象のコードの隣に置かれ、変更は同じレビュー工程を通る。テスト定義をほかのソースファイルと同じように追跡し差分を見たいエンジニアリング組織に向いており、Web ダッシュボードだけに置く必要はない。