はじめに
既存の業務システム（Windowsのデスクトップアプリ）で、手作業の画面テストを自動化しています。実装にはClaude Codeを使い、既存の「試験項目書」をもとにテストを書いてもらいました。
最初に流したときは、ほとんどのテストが落ちました。ところが、原因を調べると、アプリが悪いとは限りませんでした。
- テストのコードが間違っている
- 試験項目書が古い、または間違っている
- アプリに本当にバグがある
この記事では、落ちた原因をこの3つに分けて進めた方法と、そこでハマった点を紹介します。
なお、記事中の画面名やデータは、説明用に置き換えた架空のものです。
1. 試験項目書は、いつも正しいわけではない
AIは、試験項目書に書かれたとおりにテストを書きます。そのため、項目書が間違っていれば、正しく動いているアプリでもテストが落ちます。
実際に見つかった項目書の誤りには、次のようなものがありました。
- 画面名が変わったのに、操作欄に旧名のまま残っている
- 別の画面の項目書をコピーして、画面にない項目の説明が混ざっている
- 仕様変更のあとに、確認内容が更新されていない
- 「顧客名」と「取引先名」のような、単純な書き間違い
人が手作業でテストしているときは、「この書き方は古いけれど、意味は分かる」と読み替えてしまいます。自動化すると、その読み替えができなくなり、誤りが表に出てきます。
2. 落ちた原因を、3つに分類する
AIに実装を任せるときに、判断の基準を最初に決めておきました。落ちた項目は、次の3つに分類します。
| 分類 | 状態 | 対応 |
|---|---|---|
| ① 項目書の誤り | 画面やコードの状態が明らかに正しく、項目書が古い・間違っている | 項目書を直す |
| ② どちらが正しいか決められない | 項目書に書かれていない、または、仕様としてどちらもありうる | 設計者に確認する |
| ③ アプリのバグ | 項目書が正しく、アプリが期待と違う動きをしている | 再現手順を付けて報告する（項目書は直さない） |
大切なのは、②を無理に決めないことです。
例えば、注文一覧を昇順に並べたとき、「日付が空の行を先頭に出すか、最後に出すか」が項目書に書かれていないことがあります。現状の動きに合わせてテストを書くこともできますが、それが本当に正しい仕様かどうかは、AIにも私にも分かりません。
そこで、AIには、次の形で確認事項をまとめてもらいました。
【確認事項】注文一覧の昇順で、日付が空の行をどこに出すか
現状 ：空の行が先頭に出る
選択肢：A. 後ろに出すようアプリを直す
B. 現状のままにして、項目書に明記する
C. 空の行を除いて確認する
現状、見立て、選択肢をそろえておくと、設計者も答えやすくなります。
3. 「直していい」と「直してはいけない」を分ける
この分類で、次の失敗を避けられました。
-
バグを、テストに合わせて隠してしまう
アプリのバグを、「項目書のほうを直せばテストが通る」と処理してしまうと、不具合が残ったままになります。③に分類したものは、項目書を直しません。 -
項目書を、勝手に書き換えてしまう
直す場合も、元のファイルは残し、別名のコピーに反映します。直した箇所は色を変え、「変更前の文」と「理由」をコメントに残しました。 -
「たぶん」で直してしまう
根拠がコードやドキュメントにはっきりあるものだけを、①にします。確度が低いものは、②に回します。
AIは、迷っても、それらしく直してしまうことがあります。「どの場合に直してよいか」を先に言葉にしておくと、判断がぶれにくくなります。
4. ハマった点：テスト側の誤り
3分類のうち、いちばん最初に疑うべきなのは、実はテスト側の誤りでした。
最初の全件実行では、ほぼすべてのテストが失敗しました。原因は、アプリではなく、テストのコードでした。
- 別の画面を呼び出す前に「いま開いている窓」を控えていたため、呼び出した画面の窓を、不要な窓と取り違えて閉じていた
- チェックボックスをクリックしても、状態が切り替わらないことがあった（切り替わらなかったときは、キー操作で押し直すようにした）
- 操作したい行が、一覧の下のほうにあって、画面に見えていなかった
大量に落ちたときは、アプリを疑う前に、テストの基本動作（起動、画面の特定、操作の確実さ）を確認します。
5. ハマった点：テストのデータと接続先
自動化テストは、修正の前後で「出てくる値が同じか」を確認するために使います。毎回同じ結果になるように、テスト専用のDBを用意して、毎回同じデータに戻すことにしました。
ここでも、いくつかハマりました。
-
接続先は、データで確認する
画面のタイトルに「テスト用DB」と表示されていても、実際は本番を見ていたことがありました。それ以降は、「本番とテスト用で件数が違うデータ」を読んで、接続先を判定するようにしました。 -
テスト用アプリに、ログインの処理がなかった
ログインを通らず画面を開くと、絞り込みに使う所属情報が空になり、そこに依存する項目がまとめて落ちました。
6. 「スキップ」を、隠さない
最終的なテスト結果は、成功が大半で、失敗は0件、残りがスキップでした。スキップが全体の4分の1ほどあります。
失敗を0件にするだけなら、期待値を現状に合わせれば済みます。しかし、②に分類した項目を、合格にしたくありませんでした。
そこで、②は「判定できなかった」として、スキップにして理由を残しました。
- 項目書とアプリの動きが違うが、どちらが正しいか決められない
- 確認したい条件のデータが、テスト用DBに存在しない
「全部緑」にするより、何が確認できていないかを、一覧で見える形にするほうが、次の判断につながります。
おわりに
AIで自動化テストを実装するときは、次の流れを意識すると進めやすくなります。
落ちた原因を3つに分ける → ②は決めずに確認事項にする → ③は項目書を直さずに報告する → 確認できていない項目も残す
AIは実装を速くしてくれますが、「何が正しいか」を決めるのは人です。試験項目書の誤りも、AIが書いたテストによって、はじめて見つかりました。
自動化は、テストが増えるだけでなく、仕様書の曖昧さを見つける作業にもなります。まずは、小さな画面1つで試してみてください。