ソフトのテスト経験がなくても、AIで作ったアプリをテストする方法

AIでアプリを作りました。ハッピーパスでは動きます — 名前を打ち込み、ボタンをクリックすると、成功画面が出る。さて、次は？3人のベータユーザーに送る準備はできていますか？チームには？顧客には？

ソフトの経験がないと、テストは「本物の開発者」がやること — フレームワークやアサーションやCIパイプラインを使って — のように感じられます。良い知らせ：たいていのテストは、実際にはそういうものではありません。たいていのテストは、特に小さくて新しいものを出すときには、一人の人が意図を持ってあちこちクリックすることです。あなたにもできます。この記事は、それを意図的にやって、ユーザーより先にバグを見つけることについてです。

目標は、AIで作ったアプリをプロのようにテストすることではありません。それを、本気でうまくいってほしいと願う、心配性の友達のようにテストすることです。

2つのリストの技

何かをクリックする前に、白紙のドキュメントを前に10分座って、2つのリストを書きましょう。

リストA — ハッピーパス。 ユーザーがこのアプリでやるはずのことは、3つか4つ何でしょう？典型的なSaaSなら、こうかもしれません。サインアップする、最初のプロジェクトを作る、チームメイトを1人招待する、結果をエクスポートする。ディレクトリ型のアプリなら、検索する、絞り込む、掲載をクリックする、保存する。3つか4つの本物のフローを、平易な言葉で。

リストB — アンハッピーパス。 もしユーザーが、ほぼ正しいけれどちょっと違うことをしたら？メールアドレスを打ち間違える。フローの途中で戻るボタンを押す。タブを2つ開いて、両方で同じものを編集する。空のフォームを送信する。Wordドキュメントの中身を — 書式ごと — テキスト欄に貼り付ける。ノートパソコンを閉じて、10分後にまた開く。すでにシステムに存在するメールアドレスを使ってチームメイトを招待しようとする。

ハッピーパスのリストは、あなたのAIアプリビルダーが最適化したものです。AIがコードを書きながら頭の中でテストしたものです。アンハッピーパスのリストは、バグが住んでいる場所です。なぜなら、ほとんど誰も — AIも、プロンプトを書いていたときのあなたも — そうしたケースについて考えていなかったからです。

実際にテストするときは、まずリストAを歩いて、基本が動くことを確認します。それから、時間の大半をリストBに費やしましょう。リストBに価値があります。リストBはまた、物事が横道にそれたときにアプリに実際どう動いてほしいかを見つける場所でもあり、それはしばしばAIビルダーとの確認のための会話を促します（「フォームが半分しか埋まっていないとき、警告すべき？それとも自動保存すべき？」）。

わざと壊す3つのこと

リストができたら、AIで作ったアプリの本物のバグの大半を捕まえる、3つのカテゴリを挙げます。

空っぽで奇妙な入力。 何も埋めずにフォームを送信する。1つの欄だけ埋めて送信する。500文字の名前を送信する。絵文字入りの名前を送信する。名前を期待する欄にURLを貼り付ける。メール欄に「test」、「test@」、「test@example」、そしてアドレス「a@b.co」を試す — 正当に短いメールを受け付けるか？AIアプリビルダーはしばしばバリデーションを足しますが、そのバリデーションは両方向に間違いうる — 厳しすぎる（本物のユーザーを弾く）か、緩すぎる（ゴミを受け付ける）か。

後ろと横へ進む。 ほとんどのアプリは、従順な団体ツアーのように歩けば問題なく動きます。誰かが探検し始めた瞬間に壊れます。戻るボタンをクリックする。また進むをクリックする。フローの途中でページを再読み込みする。同じページを2つのタブで開いて、両方で編集する。ログアウトして、また入る。「元に戻す」ボタンがあれば、3回連続でクリックする。これらはエッジケースではありません。これらが、本物の人がソフトを使うやり方です。

そのあとのデータ。 アプリが作るものを作りましょう。プロジェクト、投稿、レコード、何でも。それから明日、戻ってくる。まだそこにありますか？書式は残りましたか？編集したら、その編集は保存されますか？削除したら、本当に消えていますか、それとも再読み込みすると戻ってきますか？AIアプリビルダーはしばしば「作成」のフローは完璧にこなして、作るものすべてが残り、あとで編集できる必要があることを忘れます。

「十分」がどんなものか

AIで作ったアプリを、完璧にはテストできません。ソフトはあまりに込み入っていて、あなたの時間はあまりに貴重です。問いは「完璧か」ではありません — 「次に目の前に出す人たちにとって十分か」です。

借りられる、おおまかな階層を挙げます。

デモするのに十分： ハッピーパスがクラッシュせずに動く。ボタンは行くべき場所へ行く。何も切り取らずに画面録画を見せられる。

好意的なユーザーに十分： アンハッピーパスがデータを失わない。フォームは黙って失敗するのではなく、何が間違っているかを教えてくれる。ページを再読み込みしても壊れない。3人の友達が、助けを求めて連絡してこずに使える。

有料ユーザーに十分： アプリが、会ったこともないユーザーを扱う。彼らのブラウザ、彼らのデータ、彼らの習慣を。物事が壊れたときに気づく手段がある（基本的なエラートラッキングで十分です — 凝ったダッシュボードは要りません）。すでに使っている人たちを壊さずに、修正して再デプロイできる。

たいていのビルダーは「好意的なユーザー」のレベルで出して、フィードバックが来るにつれてアップグレードします。それが正解です。間違いは、その中間のステップなしに「デモするのに十分」から「有料ユーザーに十分」へ一気に飛ぼうとすることです。好意的なユーザーは、本物のユーザーが見つけるようなものを見つけます — でも、それに腹を立てません。その隙間を活かしましょう。

AIにテストを頼むとき

AIアプリビルダーはテストを手伝えますが、何がほしいかを具体的に言わなければなりません。「テストを足して」は悪いプロンプトです。テストのように見えて、おそらく通るコードを生成しますが、あなたが気にする何かを実際にはチェックしません。そうした自動生成のテストのほとんどは、1+1がまだ2であることを確認しています。

より良いプロンプト：「メール欄を空にしてサインアップフォームを送信しようとしたら、クラッシュしました。それがどこで処理されているか見つけて、代わりに親切なエラーを表示するチェックを足して。」具体的なバグ、具体的な修正、具体的な結果。AIはこれが得意です。「私のアプリにバグがないようにして」は苦手です。なぜなら、それはタスクではなく — 願い事だからです。

AIビルダーが得意なもう1つのことは、あなたのバグを再現することです。何をしたか、何を期待したか、何が起きたかを説明すれば、ビルダーはたいていコードを追って修正案を出せます。あなたに必要な規律は、その3つを明確に書き留める規律です。たいていの初心者のバグ報告は、「動きません」の何らかの版です。たいていの直せるバグ報告は、「Xをクリックして、Yを期待したのに、Zになった」です。

テストはクリックだけでなく、読むこと

最後に1つ。AIで作ったアプリの中のすべての行を理解する必要はありません。でも、少なくともざっと目を通すべきです。AIがたった今変更したファイルを開く。足された関数を読む。すべてのキーワードが何を意味するかを知る必要はありません — その関数が、頼んだことをやっているように見えるかを知る必要があるのです。

AIで作ったバグの多くは、「コードが壊れている」ではありません。「コードが、望んだのとほんの少し違うことをしている」です。欄が間違った場所に保存される。ボタンが1つのものは更新するが、関連するものは更新しない。「削除」ボタンが削除する代わりに隠す。実際に作られたものを読まないと、これらは捕まえられません。

コードを、自分で書かなければならないものではなく、監査できるものとして扱いましょう。それが、信頼できるAIで作ったアプリと、ただ動くことを願うだけのアプリとの違いです。

シンプルな版

ほかに何も覚えていないとしても：2つのリストを書き、わざと物事を壊し、どの「十分」のレベルで出すかを決めましょう。AIで作ったアプリのバグのほとんどは、巧妙ではありません。誰もわざわざ書き出さなかった、アンハッピーパスのリストの上に座っているのです。

小さな宿題がほしいなら：作ったアプリを1つ選んで、4つのことを試してみてください — 空のフォームを送信する、フローの途中で再読み込みする、レコードを編集して翌日に確認する、見ていないところで友達に使ってもらう。壊れたものが、あなたの本物のバグリストです。それ以外はすべて、先延ばしです。