AIでテストケースを作る方法｜正常系だけで終わらせない頼み方

「この機能のテストケースを考えて」と渡すと、機能の説明をなぞった一覧が返ります。説明に書かれているのは、うまくいったときの話だけだからです。

異常系は、仕様書に書かれていないことが多い。通信が切れたら、権限が無かったら、途中で画面を閉じたら。こういう場面は、こちらの頭の中にもはっきりとは無いことがあります。

だから、出てこないのは相手の問題ではなく、渡した材料の問題でした。観点のほうを先に渡すようにしてから、返ってくる一覧が変わりました。

もう一つ理由があります。異常系は数が決まらないことです。正常系は機能の数だけですが、失敗の仕方は無数にあります。区切りを与えないと、どこまで挙げればよいか決まらないので、無難なところで止まります。

1. 01　エラー：落ちたとき何が見えるか

   処理が途中で失敗したとき、利用者に何が見えるか。原因と次の行動が伝わるか。落ちたまま黙って終わっていないか。

2. 02　境界値：0件・1件・上限の前後

   0件のとき、1件のとき、上限ちょうどのとき、上限を1つ超えたとき。空の状態は特に忘れられます。

3. 03　権限：拒否される側も確かめる

   ログインしていない人、他人のデータ、期限が切れた状態。許される側だけでなく、拒否される側も確かめるのがここです。

4. 04　通信の失敗：圏外・切断・二重送信

   圏外、途中で切れる、遅い、同じ操作が二重に飛ぶ。成功だけを前提にした画面は、ここで固まります。

5. 05　状態の残り：時間差で出るもの

   前の画面の値が残る、キャッシュが古い、再起動して初めて直る。時間差で出るものは、一度の操作では見つかりません。

頼み方で一番効いたのが、この一言でした。「期待どおりに成功する場合と、期待どおりに失敗する場合を同じ数書いてください」。

片方だけだと、何も見ていない確認ができます。たとえば転送の設定を足したとき、正しい行き先に着くことだけを見ても足りません。存在しない対象を指定したときに、ちゃんと落ちるかまで見て初めて、その設定が効いていると言えます。

私は検査スクリプトを足すときも同じで、わざと壊して落ちることまで確かめます。行き先のファイル名を存在しないものに変えた場合と、対象を1つだけ隠した場合の両方で落ちるのを見てから、その検査を信用します。

通っているのに守られていない検査は、無いより悪い。守られていると思い込むぶん、人の確認までやめてしまうからです。

同じ数、という指定にも理由があります。「異常系も出して」だと1つか2つで終わりますが、数をそろえろと言うと、無理にでも探します。その中に、こちらが考えていなかった壊れ方が混じることがありました。

長いですが、書いているのは観点と出力の形だけです。同じ依頼を何度もするなら、この文面ごと手順として残すと、毎回打たずに済みます。

テストが緑なのに守られていない、という状態を実際に作ったことがあります。

地図の部品が既定で位置情報を送っていたので、起動時に切る処理を入れました。そのとき「利用者が自分で決めたかどうか」を調べるつもりで書いたコードが、部品が登録した既定値まで一緒に拾う書き方になっていた。結果、切るべき場面で切らない判定になります。

テストは通っていました。判定の基準が間違っていたので、間違った基準どおりに動いていただけです。気づいたのは、新規インストールの状態を実機で作って、設定ファイルの中身を直接開いたときでした。

テストが緑であることは、仕様どおりであることを意味しません。何を見ているテストなのかを、たまに疑う必要があります。

一覧が返ってきたら、そのまま実装しません。先に2つ見ます。

一つは、この機能で一番困る壊れ方は何かを自分で考えて、一覧に入っているか照らすこと。入っていなければ足します。ここは頭の中にしかない情報なので、出てこなくて当然です。

もう一つは、確かめられない項目を落とすこと。「快適に動作すること」のような、通ったかどうかを判定できないものは、テストの形をしていてもテストではありません。判定できる形に直せるなら直し、直せないなら落とします。

落とす判断は早めにします。一覧に残っていると、いつか誰か（数か月後の自分）が実装しようとして、判定の基準を自分で決めることになるからです。

提出前に見る項目の一覧はアプリ公開前チェックリスト。全部通したのに問題が出た六つにまとめています。あちらが出す前の確認で、この記事は洗い出しの作り方です。

観点を渡すと、今度は一覧が長くなりすぎます。全部を実装すると維持できません。

私は「一度実際に起きたこと」を優先して残し、起きるかもしれないものは落としています。想像で足したテストは、たいてい本当に困る場面を外しました。

外したものも、消さずに理由を添えて残します。次に同じ判断をするとき、なぜ入れなかったのかが分かるからです。

数が増えてきたら、落ちたときに何を直せばよいかが一目で分かるかを見ます。失敗の文言が「検査に失敗しました」だけだと、結局こちらが調べることになる。どのファイルの何が、どうあるべきなのに、いまどうなっているか。ここまで出させておくと、あとの自分が助かります。

• 一番困る壊れ方が一覧に入っているか照らす。
• 判定できない項目は落とす。
• 同じことを二度見ている項目はまとめる。
• 実機でしか出ないものに印を付ける。

全部を自動で確かめられるわけではありません。分ける基準を持っておくと、テストが増えすぎません。

私が機械に回しているのは、間違えても自分で気づけないものです。書式の食い違い、台帳との不一致、リンクの行き先、画面のはみ出しや文字の切れ。どれも見た目が正常なまま中身だけ違うので、人が毎回見ても見落とします。

逆に、画面が真っ白になる類は検査にしていません。放っておいても気づくからです。ここを区別しないと、落ちる理由が増えて、やがて誰も読まなくなります。

実機でしか出ないものも分けています。権限のダイアログ、通知、課金の画面。これらは手元の環境では本物と同じになりません。自動で確かめるふりをするより、実機で見る項目として一覧に残すほうが誠実でした。

それでも通り抜けるものは残ります。テストを全部通して公開したのに、公開後に食い違いが出た経験はテストは全部通った。それでもアプリの公開後に6つ問題が出たに書きました。

上から順に入れていくと、数が少ないうちから効きます。逆に下から入れると、検査の本数だけ増えて、困る場面には当たりません。

AIにテストケースを出させると正常系ばかりです。

観点を先に渡してください。エラー・境界値・権限・通信の失敗・状態の残りの5つです。異常系は仕様書に書かれていないことが多く、渡す材料が無いので出てきません。相手の問題ではなく、渡した材料の問題でした。

異常系を「出して」と頼んでも1つ2つで終わります。

「成功する場合と同じ数だけ挙げて」と指定してください。異常系は数が決まらないので、区切りを与えないと無難なところで止まります。数をそろえろと言うと無理にでも探すので、考えていなかった壊れ方が混じります。

テストが全部通れば安心ですか？

テストが緑であることは、仕様どおりであることを意味しません。私は判定の基準そのものが間違っているテストを書いたことがあります。間違った基準どおりに動いていたので、通っていました。何を見ているテストなのかを、たまに疑う必要があります。

出てきた一覧をそのまま実装していいですか？

いけません。2つ見ます。この機能で一番困る壊れ方が入っているか（頭の中にしかない情報なので出てきません）と、判定できない項目が混じっていないか。「快適に動作すること」はテストの形をしていてもテストではありません。

どこから自動テストにすればいいですか？

間違えても自分で気づけないものからです。書式の食い違い、台帳との不一致、リンクの行き先。見た目が正常なまま中身だけ違うので、人が毎回見ても見落とします。画面が真っ白になる類は放っておいても気づくので、後回しで構いません。

テストが増えすぎて維持できません。

一度実際に起きたことを優先して残し、起きるかもしれないものは落としています。想像で足したテストは、たいてい本当に困る場面を外しました。落としたものも、消さずに理由を添えて残します。

観点を渡すと、今度は一覧が長くなりすぎます。全部を実装すると維持できません。残すかどうかは、起きたことがあるかで決めています。

実機でしか出ないものは、自動にせず一覧に残します。権限のダイアログ、通知、課金の画面。手元の環境では本物と同じにならないので、自動で確かめるふりをするより、目で見る項目として残すほうが誠実でした。

それでも通り抜けるものは残ります。テストを全部通して公開したのに、公開後に食い違いが出た経験はテストは全部通った。それでもアプリの公開後に6つ問題が出たに書きました。