Iris

テストはスクリプトではなく文から始まる。シナリオを打ち込み、ページを指定すると、Irisが指示を実行可能な流れに変換する。実行前にプレビューのステップがあり、エージェントがあなたの言葉をどう読んだかを見られるので、誤解を早い段階で捕まえられる。自動化の訓練を受けたエンジニアがいないチームにとって、テストがそもそも書かれるかどうかを決める機能だ。

各エージェントは画面を見ながら同時にテキストも読む。人と同じやり方だ。この組み合わせのおかげで、Irisは動的に読み込まれる内容、UIの状態、ネットワーク応答、ライブ更新を特別なスクリプトなしで扱えるとしている。サイトが変わったときは再帰的な学習でエージェントが自ら調整し、いきなり失敗しない。自己修復という約束の中核はここにある。

作業はプロジェクトに収まり、各プロジェクトは一連のテストを抱える。ひとつずつでも一括でも実行できる。テストは指示、検証ルール、成功条件、そして専用のエージェント設定をまとめたものだ。実行はそのつど、ステップ、所要時間、スクリーンショット、録画を含む記録として保存されるので、失敗はスタックトレースだけでなく証拠を伴って届く。

プロジェクト設定からcookie、localStorage、sessionStorageを読み込めるため、ログインの後ろにある画面にも到達できる。これは重要だ。実際のアプリのほとんどは認証の内側に隠れていて、公開ページしか触らないテストは、本番で本当に壊れる流れを見逃す。

IrisはGitHubと接続し、pull requestでのテスト起動、イシュー作成、チェック結果の公開を行う。SlackとDiscordにはリアルタイム通知と失敗アラートを送る。対応するパイプラインとしてGitHub Actions、CircleCI、Jenkins、GitLab CIも挙げている。狙いは、変更のたびにテストを走らせ、チームがすでに使っているツールに結果を届けることだ。

トークン認証付きのtRPC APIを公開し、テスト、エージェント、プロジェクト、組織を扱える。バッチやフィルタ付きクエリにも対応する。Irisはコントロールプレーンと分散エージェント網の関係も説明しており、コードは公開のGitHub組織に置かれている。TypeScript SDKはまだ提供されておらず、開発中だとしている。

実行が終わると、通ったステップ、失敗した箇所、録画、再現に必要な文脈を含むレポートができる。レポートはメールで共有でき、過去の実行と比較できる。バグを仕分けるチームにとって、録画はたいてい書かれたログより速く答えを出す。