【ITニュース解説】I Let AI Write My Tests for 6 Months. Here Is What Actually Survived Production

最近、AIがテストコードを自動生成するという話題をよく耳にする。あるチームメンバーがAIに生成させたテストコードを共有し、「なぜ手書きでテストを書いているのか」と問うたことから、この話題が始まる。そのAI生成テストは確かに合格したが、実際には何も検証していなかった。ボタンをクリックし、数秒待って、ページが存在することだけを確認する、いわば「見せかけの成功」だった。

筆者は3年以上テスト自動化に携わり、特にウェブではPlaywright、モバイルではFlutterを使用している。過去半年間、このテスト自動化のワークフローにAIを積極的に取り入れてきた。その結果、AIが本当に役立つ場面と、そうでない場面が明確になったという。

まず、AIが真価を発揮する場面について説明する。一つ目は、バグ報告からテストケースの骨子を生成することだ。品質保証（QA）チームが「クーポン適用時に最後のアイテムを削除してもカート合計が更新されない」といった具体的なバグ報告を平易な言葉で記述する。これを既存の画面部品を定義したファイル（ページオブジェクトファイル）と共にAIに入力すると、数分以内に合理的な失敗するテストコードのひな形が得られる。完璧なテストではないが、プログラムの読み込み設定（インポート）、テスト環境の準備（フィクスチャセットアップ）、画面操作の手順（ナビゲーションステップ）といった面倒な定型作業の多くが自動化され、手作業での入力が約6割削減されるという。人間は最終的な検証部分（アサーション）を書き直すだけで済むのだ。

二つ目は、自分が書いたものではない、不安定なテスト（flaky test）の原因究明だ。テストが20回中1回だけ失敗するといった状況はよくある。数年前に退職した人が書いたテストで、複数の待機処理や固定されたタイムアウト設定が含まれている場合、そのコードを解析するのは非常に骨が折れる。このような時、テストコードと実行時の詳細なログ（トレース）をAIに入力し、競合状態（race condition）の可能性を尋ねると、AIは半分くらいの確率で正しい仮説を提示してくれる。たとえ間違っていたとしても、問題解決のための出発点となる仮説が得られるため、ただファイルを眺めているよりも早く原因にたどり着ける場合が多い。

三つ目は、複雑なウェブページの構造（DOM）から安定した要素の特定方法（ロケーター）を提案してもらうことだ。ウェブページを構成するHTMLコードの一部をAIに与え、「最も安定したロケーターは何か」と尋ねると、通常は「役割に基づいた取得（getByRole）」や「ラベルに基づいた取得（getByLabel）」といった、より堅牢な方法を推奨してくれる。これは、人間が書きがちな複雑で壊れやすいCSSセレクターよりも優れた方法だ。AIはまるで、テストコードの品質向上を助ける「意見を持つ校閲ツール」のように機能する。

一方で、AIにはまだ多くの限界があり、特に重要な部分を見極める能力に欠けている。AIは、既存のコードから学習したパターンに基づいてテストを生成するため、通常想定される成功するシナリオ（ハッピーパス）のテストは得意だが、「何が問題を起こすか」という本質的な問いには答えられない。例えば、「決済の通知が二重に届いた場合どうなるか」といった問題は、実際にそうした障害を経験した人間だけが考えつくドメイン知識（業務知識）に基づいた疑問だ。筆者が実際に発見した重大なバグの約8割は、AIでは思いつかないような、誰も生成しようとはしないテストから見つかったという。

さらに、AIはモバイルウェブのテストで特に苦戦する。これは驚くべき点だが、AIモデルの訓練データはデスクトップウェブのテストコードが圧倒的に多いため、ビューポート（画面表示領域）固有の挙動、タッチ操作の対象範囲、あるいは画面が小さいときに固定ヘッダーがクリックを妨げるようなモバイル特有の問題に関する質問の品質は著しく低下する。AIは自信を持ってデスクトップ向けの解決策を提示し、それをモバイル向けだと主張することがよくある。そのため筆者は、モバイルウェブテストでAIから誤った提案が繰り返されることに辟路し、Playwrightを使ったモバイルウェブテストの独自の参照資料を作成する羽目になった。デバイスのエミュレーション、実際のタッチイベント、画面の向きの制御といった要素は、やはり実際にバグを見たことのある人間の介入が必要となる。

モバイルアプリ開発フレームワークのFlutterに至っては、さらに状況が悪い。訓練データが非常に少ないため、AIにFlutterのウィジェットテストを依頼すると、一見それらしく見えるが、実際には数世代前のAPIを使っているコードを生成することがある。アプリ全体の基本的な動作を確認するテストスイート（スモークテストスイート）を依頼しても、ウェブのパターンをFlutterの見た目に合わせて流用したような、実情に合わないコードが出てくる。このため、筆者はFlutterのスモークテストや回帰テストの環境をほとんど手作業で構築したという。個々のテスト内の定型的なコード生成にはAIが役立ったものの、テスト全体の構造に関しては全く助けにならなかった。

また、多くのAIテストツールが謳う「自己修復ロケーター」も、ほとんどが宣伝文句に過ぎないと筆者は指摘する。ロケーターが沈黙のうちに自動で修復されると、テストはUI（ユーザーインターフェース）の変更に気づかなくなり、本来検出するべきUIの変更に伴うバグを見逃してしまう可能性がある。テストは、UIが変更されたという事実を声高に知らせてくれる方がはるかに良い。

これらの経験を踏まえて、筆者の現在のテストワークフローは次のような形になっている。まず、筆者自身がテスト計画を平易な言葉で書く。具体的に何がどのように壊れるべきか、そしてそれがなぜ重要なのかを明確にする。次に、そのテスト計画と既存のページオブジェクトファイルを使って、AIにテストコードの骨子を生成させる。しかし、そこで最も重要なステップがある。それは、生成されたすべての検証部分（アサーション）を人間が書き直すことだ。AIが生成するアサーションは、単に「何かが存在すること」を確認するだけだが、人間が書くアサーションは「何かが正しいこと」を確認するという、全く異なる役割を持つ。このステップは多くの人が省きがちだが、テストの本質に関わる非常に重要な作業だと筆者は強調する。アサーションを書き直した後、テストをCI（継続的インテグレーション）環境に導入する前に、ローカル環境で20回程度実行し、その安定性を確認する。もしこの段階でテストが不安定な挙動を示す場合は、待機時間を追加して無理やり通そうとするのではなく、そのテストを削除し、最初から作り直す。

結局のところ、AIはテストを書く速度を向上させたが、「どのテストを書くべきか」という、この仕事で最も重要なスキルを向上させることはなかった。筆者は、品質保証の分野にこれから入る人々にとって、これには大きなリスクがあると警鐘を鳴らす。もし、システムがどのような場合に失敗するか（故障モード）を深く考える力を身につける前に、AIに指示を出す方法（プロンプト）だけを学んでしまうと、結果として大量の、しかし実際には何も検出しない「見せかけの成功」をもたらすテストスイートを生み出す可能性がある。筆者は既にそのようなテストスイートをいくつか見てきたという。それらは、テストが存在しないよりも悪い状況を生む。なぜなら、それらはチームに偽りの安心感を与えてしまうからだ。

この経験から筆者は、AI活用の未来について、読者との議論を求めている。「AIが生成した最も愚かなテストは何か」「自己修復ロケーターが実際に役立った経験はあるか」「FlutterやReact NativeでのAI活用はどうか」「モデルが直接ブラウザを操作するような新しいテスト手法の経験はどうか」といった問いを通じて、更なる知見を求めている。AIは強力なツールだが、その真価を引き出すためには人間の深い理解と判断力が不可欠だという点が、この話の最も重要なメッセージである。