独立したアドレスで
再送・期限切れ・同時実行を検証
1つのアドレスでは1つの経路だけを検証すれば、登録メールのテストで古い認証コードやリンク、キャッシュされたIDに邪魔されません。ここでは使い捨て受信箱を軽量なQAマトリクスとして整理し、正常系・異常系・多言語のシナリオをカバーします。
この手順は、テストする権限のある製品環境向けです。目的は大量登録ではなく、各テストID・メール・結果を正確に対応付け、問題発生時にすばやく再現できるようにすることです。
1. 最初にIDマトリクスを作成する
テスト担当者ではなく経路ごとにアドレスを割り当てます。通常登録、初回再送、リンクの期限切れ、言語切り替え、モバイル表示には、それぞれ別のアドレスを使用します。同じ経路を別のブラウザーで繰り返す場合も、新しいIDを作成してください。これにより、メールの到着順が変わっても、前回の結果を今回の結果と取り違えずに済みます。
まずRelayTmpの使い捨て受信箱でアドレスをコピーし、すぐにテストケースの行へ記録します。アドレスには明確なカウントダウンが標準で設定されているため、数時間以内に終わる連携テストに適しています。数週間にわたるテストや、同じ公開IDで継続的に受信する必要がある場合は、長期管理できるメールアドレスまたは転送エイリアスを使用してください。
| テストケース | 独立したID | 主なアサーション |
|---|---|---|
| 初回登録 | Aアドレス | メールは1通、コードは有効、ウェルカムページは一致 |
| 認証コードの再送 | Bアドレス | 待機時間が明確で、旧コードのルールが仕様どおり |
| 確認リンクの期限切れ | Cアドレス | 期限切れページが分かりやすく、再実行できる |
| 言語切り替え | 言語ごとに1アドレス | 件名・本文・リンク先が同じ言語 |
| モバイル表示 | Dアドレス | コード・ボタン・本文が切れずに表示される |
2. まず干渉のない基準ケースを実行する
ログイン状態や自動入力のないクリーンなセッションから開始します。登録を送信したら、画面の反応とトリガー時刻を記録します。すぐにアドレスを切り替えたり、メールが届く前にアカウント情報を変更したりしないでください。メールが届いたら、送信者、件名、宛先、ブランド名、コード形式、有効期限の説明を確認します。
確認リンクを開くときは、リンク先のドメインとHTTPSを確認し、その後元のページに戻って状態が同期しているか確認します。同じリンクを2回目に開くことも試してください。冪等なリンクなら確認済みの状態を維持し、1回限りのリンクなら、曖昧なサーバーエラーではなく、使用済みであることを明確に示す必要があります。基準ケースに合格してから、再送や期限切れなどの破壊的な経路に進みます。
「メールを開ける」だけでは不十分です。狭い画面でも認証コードが途中で改行されず、主要ボタンの文字がはみ出さず、暗い背景上の説明が読みやすいことを確認します。テキスト形式でも重要な操作リンクを残してください。
3. 認証コードの再送をステートマシンとしてテストする
最初の送信後は連続してクリックしないでください。まずボタンが60秒のクールダウン、または製品で定めた待機状態になったことを確認し、カウントダウン終了後に2回目を実行します。2通の到着順、コード、有効期限を記録し、古いコードと新しいコードを順番に送信します。
最も明確に記録すべきなのはサーバー側のルールです。新しいコードの生成直後に古いコードが無効になるなら、古いコードには正確なエラーを返す必要があります。短時間だけ併存を許可するなら、2つのコードの期限をそれぞれ計算します。ページはボタンの無効化だけに依存してはいけません。更新や別タブによって再度リクエストが送信される可能性があるためです。同時実行の制御はサーバー側のルールで担保してください。
- 同じタブでクールダウン中に繰り返しクリックした場合、タスクは1件だけ生成されるか
- ページを更新した後もクールダウンは維持されるか
- 2つのタブで同時にクリックした場合、説明できない複数の有効コードが発生しないか
- メールが順不同で届いたとき、どのコードを使うべきか画面に表示されるか
- エラー回数が上限に達した後、復旧手段があるか
4. コードとリンクの期限切れを境界の両側でテストする
「明らかに期限切れ」になるまで待ってからクリックするだけでは不十分です。期限の1分前に1回、期限を少し過ぎてからもう1回検証し、時刻の境界と文言が一致しているか確認します。テスト端末の時刻でサーバーがコードを受け入れるかどうかが決まってはいけません。端末の時計を変更しても受け入れられるなら、検証場所が誤っている可能性があります。
期限切れページでは、次に何をすべきかを説明する必要があります。どこへ戻るのか、再送できるのか、メールアドレスを再入力する必要があるのかを示してください。再送で新しいリンクが発行される場合、古いリンクは既定の方針に従って無効化する必要があります。使い捨て受信箱自体にも有効期限があるため、長時間待つ前に受信箱を延長してください。「テスト用受信箱の期限切れ」を「製品リンクの期限切れ」と誤判定するのを防げます。
境界テストの記録項目
- サーバーが公開または合意した有効期限
- 期限前に最後に成功した時刻
- 期限後に最初に失敗した時刻
- 失敗ページのエラー種別と復旧入口
- 再送後も古いリンクを使用できるか
5. 多言語テストは本文の翻訳だけではない
言語ごとに独立したアドレスを作成し、実行前に製品の言語を切り替えます。メールの件名、プレヘッダー、本文、ボタン、フッターが同じ言語パックから生成されているか確認してください。「件名は英語、本文は日本語」のような混在は認めないでください。日付、タイムゾーン、数値形式も対象言語の慣習に合わせます。
リンクでも言語コンテキストを維持する必要があります。日本語メールの確認ボタンが英語のエラーページを開いてはいけません。再送後のメッセージも既定の言語に戻ってはなりません。長いフランス語やポルトガル語のボタンは一般的なモバイル幅で確認し、日本語本文では不自然な空白や改行に注意します。HTMLテンプレートが正常でも、テキスト形式の代替コンテンツを見落とさないでください。
6. 次回の回帰テストに使える記録を作成する
良い記録はスクリーンショットの寄せ集めではなく、再実行できる手順です。各行に、前提状態、アドレス番号、実行操作、期待結果、実際の結果、4つの主要時刻、証拠リンクを含めます。失敗後に再検証する際は、同じIDの復旧フローをテストしている場合を除き、新しいアドレスを使用してください。
完了後はテストデータを削除し、すべての長期アカウントの復旧設定から一時アドレスを削除します。使い捨てメールの利点は、タスクの境界を明確にできることです。テスト終了後もアカウント復旧に依存しているなら、ID戦略が本来の目的から外れています。
古いメールの影響を受けないIDを作成する
アドレスをコピーし、登録を実行して受信箱を更新します。最初の結果を、その後の異常系の基準として使用してください。