アプリを公開前にテストする方法：実践的なリリース前計画

公開前にアプリをテストするには、ユーザーが完了すべき数少ない操作の流れを書き出し、それぞれを初めて使う新規ユーザーとして、パソコンとスマホの両方で実行します。そのうえで、空のデータ、不正な入力、2つ目のアカウント、遅い回線など、うまくいかないケースを試してください。お金や個人データに関わるものは特に注意深くテストし、公開後には公開URLで主要な操作を繰り返しましょう。最後に、アプリを初めて使う人が操作するのを観察して締めくくります。

このために、QAチームやテストフレームワークは必要ありません。必要なのは、リスト、1〜2時間の時間、そして実際にリストに沿って操作する根気です。

ステップ1：重要な操作の流れを書き出す

操作の流れ（ジャーニー）とは、ユーザーが最初から最後まで完了しようとする一連の作業のことです。ほとんどのアプリには、本当に重要な流れが3〜6個あります。たとえば予約アプリなら次のようになります。

1. アカウントを作成し、確認を完了する
2. クラスを探して予約する
3. 予約をキャンセルする
4. クラスのパスを購入する
5. スタッフ：今日の予約を確認する

ユーザーストーリーを書いている場合は、その受け入れ基準がそのままテストケースになります。書いていなければ、流れごとに1行ずつ、何をもって「成功」とするかを書きましょう。

重要度をつけてください。お金を生む流れや、すべてのユーザーが通る流れ（会員登録、ログイン、中心となる操作）は、最初に最も手厚くテストします。

ステップ2：新規ユーザーとして正常な流れをテストする

「正常な流れ（ハッピーパス）」とは、想定どおりに操作が進むことです。初めて訪れた人の立場で、次のようにテストしましょう。

• プライベートブラウズのウィンドウを使い、ログインしていない、保存されたデータがない状態にします。
• 実際に確認できるメールアドレスを使った新しいアカウントを作ります。
• ブックマークしたページからではなく、トップページやリンクから始めます。

新規ユーザーはデータを持っていません。リストが空のとき、プロフィールに写真がないとき、まだ何も購入されていないときにだけ出るバグは多くあります。テストデータで満たされた自分のアカウントでは、こうしたバグは隠れてしまいます。

ステップ3：わざと壊してみる

それぞれの流れを、今度はわざと間違った操作で繰り返します。

再読み込みは特に注意してください。クリックで操作すると動くのに、深いページを再読み込みすると404が出る場合は、デプロイ後に404エラーを直す方法をご覧ください。

ステップ4：2つのアカウントで権限をテストする

アカウントを持つアプリにとって、これは最も重要なテストで、かつ最も省かれがちなテストです。

通常のユーザーAとBを作成し、（アプリに存在するなら）管理者も作ります。

• Aとしてレコードを作成します。Bとしてログインし、そのレコードを見られるか、編集できるか、削除できるかを確認します。設計上そうすべきでなければ、見られたり変更できたりしてはいけません。
• Aとして、自分のレコードの1つのURLをコピーします。Bとしてログインし、そのURLを直接開きます。
• 通常のユーザーとして、管理者ページのURLを直接入力して開けないか確認します。
• 完全にログアウトしてから、同じURLを試します。

ここで問題が見つかったら、修正するまで公開しないでください。チェックはボタンを隠すのではなく、サーバー側で行う必要があります。詳しくはAIで作ったアプリのセキュリティチェックリストをご覧ください。

ステップ5：実機でテストする

狭いブラウザのウィンドウではなく、実際のスマホでアプリを開きましょう。

• ズームしなくても、すべてのボタンをタップできるか。
• 入力中の項目が、キーボードに隠れないか。
• 表やはみ出す内容が、横にページを押し広げるのではなく、スクロールまたは折り返されるか。
• ピンチしなくても文字が読めるか。

可能であれば、iPhone（Safari）とAndroid（Chrome）を少なくとも1台ずつ試してください。特にSafariは、日付、動画、固定配置の要素で独特の挙動があります。

ステップ6：お金とメールを最後までテストする

カード決済やメール送信に関わるものは、最初から最後まで通して確認する必要があります。

決済。 決済サービスのテストモードと、テスト用のカード番号を使いましょう。成功した決済、拒否されたカード、キャンセルされた決済を確認します。決済後に、注文やサブスクリプションが決済サービスの管理画面だけでなく、アプリ内にも反映されるかを確認してください。アプリが決済サービスからのWebhook（サーバーに送られる通知）に依存しているなら、開発環境だけでなく公開されたアプリにも届くかを確認します。そして公開前に本番用のキーに切り替え、少額の本物の購入を1件行い、その後に返金してください。

メール。 2〜3社の異なるメールサービスで、実際のアドレスを使って会員登録をします。メールが届き、迷惑メールフォルダに入らず、メール内のすべてのリンクがプレビュー用のアドレスではなく本番のドメインを指しているかを確認しましょう。

ステップ7：速度とエラーを確認する

• ブラウザの開発者ツール（右クリック→検証）を開き、主要な各ページでコンソールタブを確認します。赤いエラーは、表示上問題がなくても直す価値があります。
• Wi-Fiではなくモバイル通信で、スマホからサイトを開きます。最初の画面の表示に数秒かかる場合は、まず画像のサイズを確認してください。
• Chromeの開発者ツールにあるLighthouseなどの無料の監査ツールを実行し、パフォーマンスとアクセシビリティの概要を把握します。

ステップ8：プレビューではなく、公開されたアプリをテストする

プレビューと公開済みのアプリは、同じ環境ではありません。ローンチを人に伝える前に、公開URLで主要な操作を繰り返しましょう。

• すべての環境変数と秘密情報が、公開されたアプリに設定されているか。
• 想定どおりのデータを持った、正しいデータベースを使っているか。
• ログイン後のリダイレクトやメール内のリンクが、本番のドメインを使っているか。
• 深いページを再読み込みしたときに、正しく読み込まれるか。

ステップ9：ほかの人が使うのを見る

1〜2人に、手順ではなく目標を伝えます（「土曜日のヨガのクラスを予約してください」など）。手助けせずに見守り、どこで迷ったかをメモしましょう。わかりにくい文言や、見つけにくいボタンを見つける最も速い方法です。この方法をより大規模に行う場合は、ベータテストの実施方法をご覧ください。

バグに遭遇したら、手順、期待した結果、実際の結果を含めて、きちんと記録しましょう。良いバグレポートの書き方で書式を紹介しています。

AIにテストを手伝ってもらう

AIで作っている場合は、テストの計画と実行をAIに手伝ってもらえます。

このアプリの主要なユーザーの操作の流れを挙げ、それぞれについて壊れやすいエッジケースを挙げてください。空の状態、不正な入力、権限、再読み込みを含めてください。チェックリストにして、私が順番に確認できる形にしてください。

2人の異なるテストユーザーでログインし、ユーザーBがユーザーAの作成したものを見たり変更したりできないかを確認してください。AのレコードのURLを直接開くケースも含めます。修正する前に、見つけた内容を報告してください。

AIのテストレポートは、最初の一次チェックとして扱いましょう。お金と権限に関わる流れは、必ずご自身で操作して確認してください。

Mythexでのテスト

Mythexでは、**/testコマンドでApp Testingを実行します。エージェントがブラウザでライブプレビューを操作し、ページをクリックして回り、スクリーンショットを撮り、壊れている流れをチャットで報告します。「会員登録とクラスの予約をテストして」のように、特定の流れを指定すると最も効果的です。見つかった問題は/fix**または通常のメッセージで直し、その後にもう一度/testを実行します。App Testingはプレビューを使うため、公開後は公開URLで主要な操作を自分で確認してください。詳しくは、ドキュメントのApp Testingと、問題が起きたときのAIで作ったアプリのデバッグ方法をご覧ください。

よくある失敗

• 自分だけでテストする。データがたくさんある管理者アカウントでは、空の状態や権限のバグが隠れてしまいます。
• パソコンだけでテストする。多くのサイトでは、訪問者の多くがスマホから来ています。
• 2つ目のアカウントを省く。ユーザー間でデータが漏れることは、アプリが公開時に抱えうる最も深刻なバグです。
• プレビューを信用する。公開されたアプリは設定が異なるので、そちらもテストしてください。
• バグを直したあとに、周辺をテストし直さない。1つのフォームの修正が、コードを共有している別のフォームを壊すことがあります。

公開前チェックリスト

• 主要な操作の流れを書き出し、優先順位をつけている
• 各流れを、プライベートウィンドウで新規ユーザーとして完了できる
• 空欄、不正な入力、長すぎる入力、重複する入力を正しく扱える
• すべてのページで再読み込みが正しく動く
• ユーザーがお互いのデータを、URLを直接操作しても見たり変更したりできない
• 通常のユーザーとログアウトした訪問者が、管理者ページを開けない
• 実際のiPhoneとAndroidのスマホで動作する
• 決済をテスト済み（成功、拒否、キャンセル、その後にアプリが正しく更新される）
• メールが届き、迷惑メール扱いにならず、本番のドメインへのリンクになっている
• 主要なページのコンソールに赤いエラーがない
• 公開URLで主要な操作を繰り返した
• 見ている前で、外部の人が少なくとも1人、アプリを試した

よくある質問