テストエージェント：実用性を決める3つの条件

テストエージェントの良し悪しは失敗の質で決まります

スクリーンショット付きの赤い行は、人間が解釈することを前提としています。使える失敗レポートとは、何を試みたか、アプリケーションが実際にどう振る舞ったか、そしてどこで両者が食い違ったかを示し、修正する側が経緯を組み立て直さなくてもそのまま対処できる形になっているものです。

修正する側がコーディングエージェントである場合、この点は二重に重要になります。コーディングエージェントは、スクリーンショットを見て意図を推し量ることができないからです。評価の際は、成功した実行ではなく、実際の失敗を見せてもらってください。

2つ目：そのチェックは失敗しうるか

評価の段階で、意図的に何かを壊してみてください。保存しても値が残らないようにする、フィルターが黙ってすべてを返すようにする、といったことです。それでもチェックがグリーンのままなら、そのチェックは最初から製品につながっていなかったということです。

うまくいかない形は2通りあります。曖昧すぎて結果を判定できないチェックと、アサーションに到達する前にタイムアウトし、それが成功として報告される実行です。後者のほうが厄介です。カバレッジがあるように見えてしまうからです。

3つ目：指示がなくても実行されるか

• オンデマンドのみ。 作業中は役に立ちますが、それが終われば存在しないのと同じです。

• 変更時。 プルリクエストやデプロイをきっかけに実行されます。守ってくれるのはこのタイプです。

• スケジュール実行。 環境の変化や外部依存の変動を捕捉します。

話しかけられたときだけ動くテストエージェントは、要するに優秀な手動テスターです。それ自体に価値はありますが、あなたが買おうとしていたものではありません。

最初の1週間で見るべきこと

この3つの性質に加えて、導入がうまくいくかどうかを最初の1週間で予測できる挙動が2つあります。

生成されるカバレッジは、製品を反映しているでしょうか。それとも仕様書の形をなぞっているだけでしょうか。APIドキュメントを基に動くエージェントは、誰も使っていないものまで含めてすべてのエンドポイントを忠実にカバーする一方で、コメントの中にだけ書かれたルールを見落とします。最初のプランを読めばどちらなのかが分かりますし、早い段階で直すほうが、200件のケースになってから直すよりはるかに安上がりです。

そして、その失敗を誰かが読んでいるでしょうか。テストエージェントは手動のプロセスよりも多くのシグナルを生み出しますが、誰も消費しないシグナルは単なるコストです。1週間経った時点で、失敗が調査されるのではなく、ただ確認されるだけになっているなら、原因はたいていチームではなく失敗レポートの形式にあります。習慣として定着する前に指摘しておく価値があります。

半日でできる評価

フローを3つ記述します。1か所を意図的に壊します。何かをマージします。壊した箇所を検出し、それを使える形で報告し、指示がなくてもマージに気づくなら、そのエージェントは仕事をしています。3つのうち1つでも欠ければ、どんな機能一覧もそれを埋め合わせることはできません。

何もインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドラインでできるその他の操作は、すべてこちらにまとめています： CLIリポジトリ。

重要なのは仕組みよりもトリガーです。デプロイのイベントに紐づけておけば、誰かが判断しなくてもすべての変更がチェックされます。 GitHub App はそれをダッシュボードから行い、 GitHub Actions のステップはワークフローの内側から同じことを行います。

TestSpriteはこの3つにどう応えるか

失敗は、何を試みたか、アプリケーションが実際にどう振る舞ったか、どこで両者が食い違ったかという形で返り、人が先に解釈しなくてもコーディングエージェントがそのまま対処できます。チェックは具体的な対象をアサーションし、アサーションに到達しなかった実行が成功として報告されることはありません。そして変更をきっかけに実行されます。リポジトリを接続すれば、パイプラインがすでに生成しているデプロイを起点にテストが走ります。

カバレッジは製品そのものから生成され、自然言語で調整できます。セットアップでは、すでにお使いのコーディングエージェントに検証用のスキルが組み込まれるため、チェックの作成と実行は作業の外側ではなく、作業の中で行われます。

結果として得られるのは、半日の評価に合格する状態です。壊した箇所を検出し、それを使える形で報告し、指示がなくてもマージに気づきます。