認証メールの到着順をテストする方法

登録テストで再現が難しいのは、メールがまったく届かないケースより、送信順と到着順が異なるケースです。1通目が遅れ、2通目が先に届くことがあります。ユーザーが一覧の先頭にあるメールを開いても、入力したコードはすでに無効かもしれません。こうした状況を見分けるには、テストごとに未使用の受信アドレスを用意し、画面上のイベントとメールの受信イベントを同時に記録します。

まずテストの開始点を決める

送信前に、ブラウザーの時刻、テスト環境、登録アカウント、受信アドレスを記録します。使い捨てテストメールの受信トレイで新しいアドレスを取得し、前回のメールが残っていないことを確認してから登録フォームに入力します。同じアドレスを複数の並行テストに割り当てると、メールが同じ一覧に混在し、どのテストで送信されたのか後から特定しにくくなります。

画面に「送信成功」と表示されても、メールがユーザーに届いたとは限りません。フロントエンドのリクエストが成功したことを示す場合もあれば、メッセージがキューに登録されたことを示すだけの場合もあります。次の4つの時刻を分けて記録しましょう。ユーザーが送信を押した時刻、画面に成功が表示された時刻、メールが受信トレイに表示された時刻、ユーザーが実際にメールを開いた時刻です。サーバーログを確認できるチームは、メールサービスがリクエストを受け付けた時刻も記録できます。ただし、内部ログの時刻とユーザーの現地時刻を同じ項目に混在させないでください。

送信と到着を同じ表に記録する

最低限のテスト記録には、リクエスト番号、操作内容、操作時刻、メールの件名、受信トレイに表示された時刻、本文に記載された有効期限、実際に入力した認証コードがどのリクエストに対応するかを含めます。必要な時刻精度はシステムに応じて決めてください。秒単位で再送するケースでは、少なくとも秒まで記録します。記録は管理されたテスト環境内にのみ保存し、認証コードをそのまま公開チケットに添付しないでください。

これは、サービスがメールを秒単位で配信しなければならないという意味ではありません。不具合を調査できる証拠を残すためです。UIが到着順だけで並べ替えていると、Aのメールを最新の認証コードと誤認する可能性があります。2通の件名、本文の案内、メールの日時欄を記録し、「最新の認証コードのみ有効」と明確に説明されているか確認しましょう。

再送時にテストする項目

待機中の連続クリック

まず、ボタンが無効になるか、残りの待ち時間が表示されるかを確認します。待機中に何度もクリックしたり、Enterキーを連打したりして、最終的にメールが1通だけ送信されるか、複数送信されるかを確認しましょう。モバイルでは、アプリをバックグラウンドにしてから戻ったときにタイマーがリセットされないかもテストします。表示される待ち時間と、実際に再送できる時刻は一致している必要があります。

前のメールが後から届くケース

AとBのメールに記載されたコードを順に使って認証し、それぞれの期待結果と実際の表示を記録します。再送後に古いコードが必ずすぐ無効になると思い込まず、まず製品の仕様を確認してから、その仕様に沿ってテストを作成しましょう。さらに重要なのは、ユーザーがどのメールが現在の入力欄に対応しているかを判断できることです。

有効期限の境界

有効期限のカウントを「送信時」と「受信時」のどちらから始めるかは、アプリの仕様によります。メール本文に「10分間有効」と記載されている場合は、期限の直前と直後の両方で確認してください。キューの遅延でメールが遅れて届くと、実際に使える時間が記載より大幅に短くなることがあります。時刻と画面の案内をあわせて記録し、「まれに期限切れ」とだけ書くのは避けましょう。

メールが届かないときは、まず原因の箇所を特定する

まず、フォームに貼り付けたアドレスに抜けや空白がないことを確認し、フォームが入力を受け付けたかを確認します。次に受信トレイを手動で更新し、現在のアドレスが変更されたり、有効期限切れになったりしていないかを確認しましょう。サービス側の配信ログを確認できる場合は、送信リクエストが受け付けられたかを調べます。ユーザーにメールが見えないというだけで、受信トレイの障害だと断定することはできません。サービスによっては使い捨てメールのドメインを拒否する場合がありますが、これは入力に関するポリシーであり、配信の遅延ではありません。

新しく取得したアドレスの有効期間は初期設定で3時間です。長期の回帰テストでは、まず有効期間プランナーで作業時間を見積もりましょう。登録メールを翌日に確認したい場合は、削除されるテスト受信トレイではなく、長期転送エイリアスまたはチーム管理のテスト用メールアドレスを使います。通常登録、無効なコード、重複アカウントなどのケースを網羅するには、登録テストチェックリストに沿って1項目ずつ確認してください。

開発チームにタイムラインを共有するときの記載事項

環境、テストアドレスを伏せた形で記載したもの、リクエスト番号、各イベントの時刻、実際のメール件名、期待する動作を共有します。スクリーンショットには、原因の特定に必要なUIの状態だけを残してください。認証コード、完全なアドレス、アクティベーションリンクを公開添付ファイルとして共有しないでください。安定して再現できる場合は、「何回目の再送か」「どれくらい経過したか」「どのメールが先に届いたか」「どのコードが有効だったか」を明記すると、「メールが遅い」とだけ伝えるより、キューや状態更新の調査に役立ちます。

同じテストは管理可能な時間内にまとめ、新しいテストを始めるたびに新しいアドレスを使います。この方法なら、最終的に原因が第三者側の遅延だったとしても、何を観測し、何がまだ確認できていないかをチームに説明できます。