はじめに

既存の業務システム（Windowsのデスクトップアプリ）で、手作業の画面テストを自動化しています。実装にはClaude Codeを使い、既存の「試験項目書」をもとにテストを書いてもらいました。

最初に流したときは、ほとんどのテストが落ちました。ところが、原因を調べると、アプリが悪いとは限りませんでした。

この記事では、落ちた原因をこの3つに分けて進めた方法と、そこでハマった点を紹介します。

なお、記事中の画面名やデータは、説明用に置き換えた架空のものです。

1. 試験項目書は、いつも正しいわけではない

AIは、試験項目書に書かれたとおりにテストを書きます。そのため、項目書が間違っていれば、正しく動いているアプリでもテストが落ちます。

実際に見つかった項目書の誤りには、次のようなものがありました。

人が手作業でテストしているときは、「この書き方は古いけれど、意味は分かる」と読み替えてしまいます。自動化すると、その読み替えができなくなり、誤りが表に出てきます。

AIに実装を任せるときに、判断の基準を最初に決めておきました。落ちた項目は、次の3つに分類します。

分類	状態	対応
① 項目書の誤り	画面やコードの状態が明らかに正しく、項目書が古い・間違っている	項目書を直す
② どちらが正しいか決められない	項目書に書かれていない、または、仕様としてどちらもありうる	設計者に確認する
③ アプリのバグ	項目書が正しく、アプリが期待と違う動きをしている	再現手順を付けて報告する（項目書は直さない）

大切なのは、②を無理に決めないことです。

例えば、注文一覧を昇順に並べたとき、「日付が空の行を先頭に出すか、最後に出すか」が項目書に書かれていないことがあります。現状の動きに合わせてテストを書くこともできますが、それが本当に正しい仕様かどうかは、AIにも私にも分かりません。

そこで、AIには、次の形で確認事項をまとめてもらいました。

【確認事項】注文一覧の昇順で、日付が空の行をどこに出すか
現状　：空の行が先頭に出る
選択肢：A. 後ろに出すようアプリを直す
　　　　B. 現状のままにして、項目書に明記する
　　　　C. 空の行を除いて確認する

現状、見立て、選択肢をそろえておくと、設計者も答えやすくなります。

この分類で、次の失敗を避けられました。

バグを、テストに合わせて隠してしまう
アプリのバグを、「項目書のほうを直せばテストが通る」と処理してしまうと、不具合が残ったままになります。③に分類したものは、項目書を直しません。
項目書を、勝手に書き換えてしまう
直す場合も、元のファイルは残し、別名のコピーに反映します。直した箇所は色を変え、「変更前の文」と「理由」をコメントに残しました。
「たぶん」で直してしまう
根拠がコードやドキュメントにはっきりあるものだけを、①にします。確度が低いものは、②に回します。

AIは、迷っても、それらしく直してしまうことがあります。「どの場合に直してよいか」を先に言葉にしておくと、判断がぶれにくくなります。

3分類のうち、いちばん最初に疑うべきなのは、実はテスト側の誤りでした。

最初の全件実行では、ほぼすべてのテストが失敗しました。原因は、アプリではなく、テストのコードでした。

大量に落ちたときは、アプリを疑う前に、テストの基本動作（起動、画面の特定、操作の確実さ）を確認します。

自動化テストは、修正の前後で「出てくる値が同じか」を確認するために使います。毎回同じ結果になるように、テスト専用のDBを用意して、毎回同じデータに戻すことにしました。

ここでも、いくつかハマりました。

接続先は、データで確認する
画面のタイトルに「テスト用DB」と表示されていても、実際は本番を見ていたことがありました。それ以降は、「本番とテスト用で件数が違うデータ」を読んで、接続先を判定するようにしました。
テスト用アプリに、ログインの処理がなかった
ログインを通らず画面を開くと、絞り込みに使う所属情報が空になり、そこに依存する項目がまとめて落ちました。

最終的なテスト結果は、成功が大半で、失敗は0件、残りがスキップでした。スキップが全体の4分の1ほどあります。

失敗を0件にするだけなら、期待値を現状に合わせれば済みます。しかし、②に分類した項目を、合格にしたくありませんでした。

そこで、②は「判定できなかった」として、スキップにして理由を残しました。

「全部緑」にするより、何が確認できていないかを、一覧で見える形にするほうが、次の判断につながります。

AIで自動化テストを実装するときは、次の流れを意識すると進めやすくなります。

落ちた原因を3つに分ける → ②は決めずに確認事項にする → ③は項目書を直さずに報告する → 確認できていない項目も残す

AIは実装を速くしてくれますが、「何が正しいか」を決めるのは人です。試験項目書の誤りも、AIが書いたテストによって、はじめて見つかりました。

自動化は、テストが増えるだけでなく、仕様書の曖昧さを見つける作業にもなります。まずは、小さな画面1つで試してみてください。