あなたもCursor AutomationでE2Eテスターを手に入れよう

社内で開発中のツールに、Cursor AutomationをE2Eテスターとして組み込んだ事例だ。SlackでのリクエストやPRへのコメントをきっかけにエージェントが起動し、Playwrightで実際にアプリケーションを操作する。結果はスクリーンショット付きのレポートとしてGitHub Wikiに保存され、Slackのスレッドに通知される。テスト項目の追加を指示すると、動作確認手順書への追記PRまで作られる。定期実行のCronや、本番向けPRのリリース前確認も同じ仕組みで回している。記事が語るのは、テストコードを生成させる案ではなく、仕様である手順書から想定される操作をその場で実行させるという発想の転換だ。

AIの鬼として面白いのは、テストコードを作らせるのではなく、テスターそのものを任せた点である。AIにテストを書かせると、生成されたコードをレビューするという別の仕事が生まれる。どこを重点的に見るかの判断も人に残る。この記事は、その仕事を丸ごとエージェントに渡した。もう一つの本音は、「PASSとだけ返ってきても信用できない」という指摘だ。実施したパターンごとにスクリーンショットが残る証跡の形を重視している。AIの報告を信じるかどうかは結論の文言ではなく、証拠が見えるかで決まる。人間のテスターに依頼するときに当たり前に求めてきたことを、AIにも同じ基準で求めているのだ。

中小企業で専任のテスト担当を置くのは難しい。だが、既にある操作手順書を持っているなら、それがそのままAIへの指示書になる可能性がある。明日の一言にするなら、「テストは人が書くものではなく、手順書を実行させて証跡を残すものだ」と捉え直すことだ。最初は社内の一画面と既存の手順書1枚から試し、結果がスクリーンショット付きで残るかを確かめる。通ったかどうかより、何を見て通ったと言えるかを先に決めておくと、社内の確認作業も整理しやすくなる。