自動ソフトウェアテストエージェント：自律性をどこで止めるべきか

自動ソフトウェアテストエージェントに任せるべきこと

• 変更からテストケースを作成すること。 コードが書かれたその瞬間の文脈を持っており、細部がもっとも鮮明なタイミングだからです。

• テストを実行し、再実行すること。 機械的な作業であり、ここに人間が入っても遅延が増えるだけです。

• 明らかな失敗を切り分けること。 環境の停止、依存関係の欠落、対象への到達不能。これらに判断は要りません。

• 自ら踏んだバグの再現ケースを書くこと。 3日後にチケット上で書き起こすのではなく、バグを手元に捉えたままケースが書かれます。

手元に残すべきこと

境界線を一文で言うと

どう検証するかはエージェントに任せ、何が正しい状態であるべきかは自分たちで決め続けます。この線引きはきれいに分かれ、それぞれが実際に優れている領域と一致し、現実のチームで運用しても崩れません。

設けておく価値のあるガードレール

すべての検証は、具体的に観測できる対象を명示すべきであり、少なくとも一度は失敗するところを確認しておくべきです。曖昧な検証は、プロダクトを直す代わりに検証のほうを満たしにいくようエージェントを誘うものであり、この種の失敗は本質的に静かに進みます。

2か月目に何がうまくいかなくなるか

このやり方は最初の数週間はうまく進みますが、その後には予測可能な落ち込みが訪れます。あらかじめ見込んでおく価値があります。

エージェントは100件のテストケースを作成しました。大半は妥当で、全部に目を通した人はおらず、2〜3件は微妙に誤ったことを検証しています。その2〜3件は、プロダクトが正しく変更されるたびに失敗するようになり、レッドの意味が曖昧なものとして扱われ始めます。そこから先はおなじみの下り坂です。再実行し、やがてスキップし、最後は無視するようになります。

この対処は、問題が起きてから慌てて行うのではなく、決まった周期で行えば安く済みます。月に一度、前回以降に追加されたすべてのケースのアサーションを読んでください。手順ではなく、アサーションだけです。この規模なら1時間もかからず、放っておけばスイート全体への信頼を損なっていたであろうケースを正確に拾い上げられます。

セットアップ

ローカルに何もインストールしたくない場合は、TestSprite のダッシュボードからでも同じセットアップを行えます。CLI のそれ以外の機能がまとまっているのが、 CLI リポジトリ。

ダッシュボードからリポジトリを接続すれば、すでに生成しているデプロイを起点にテストが走ります。あるいは、自前のワークフローにステップを追加する方法もあります。

TestSprite が担う範囲と、手元に残る範囲

TestSprite が担うのは「どう検証するか」です。変更からテストケースを作成し、デプロイ済みのアプリケーションに対して実行し、再実行し、機械的な失敗を切り分けます。セットアップによって検証用のスキルがコーディングエージェントに組み込まれるため、これらはすべて作業が行われている場所でそのまま実行されます。

手元に残るのは「何が正しいか」です。テスト計画を読むこと、壊れたプロダクトでも成立してしまうアサーションを直すこと、そしてどの失敗がリリースを止めるかを決めること。通常の規模なら週に1時間ほどであり、プロダクトについての知識がテストスイートに入り込むのはここです。

この分担の利点は、再現ケースが3日後のチケットではなくバグを手元に捉えたまま書かれること、そしてリグレッションのカバレッジが机上の計画ではなく実際に起きた不具合から育っていくことです。