認証コードのテストは3つの時刻を記録

まず範囲を限定：許可された操作だけをテスト

自分が所有する、または明確な許可を得た登録・ログインフローだけをテストしてください。テスト環境と専用アカウントを優先しましょう。大量登録や頻度制限の回避、使い捨てメールによるサイトのアドレス規則の回避はしないでください。相手が使い捨てメールを明確に拒否している場合は、その制限を記録し、アドレスを変えて回避を試みないでください。

今回確認することを先に決めましょう。「メールを受信できるか」なのか、「再送後に旧コードが失効するか」なのかを明確にし、1回のテストで変える条件は1つだけにします。使い捨てメールで認証コードを受信すれば、ユーザー側で見える結果は確認できますが、送信サービスのキュー記録、SMTP応答、サーバー側の検証ログの代わりにはなりません。

3つの時刻、それぞれ何を記録するか

同じ端末の時計を使い、日付・タイムゾーン・秒まで記録してください。複数端末を使う場合は、先に時刻が同期されていることを確認します。以下のT1・T2・T3は記録用のラベルであり、バックエンドの処理が必ずこの順序で完了するという意味ではありません。

T1 リクエスト送信

送信ボタンを押した時刻を記録し、画面で受け付けられたかも追記します。クリックが成功しても、サーバーがメールシステムへ引き渡したとは限りません。インターフェースを確認する権限がある場合は、応答時刻とリクエストIDも記録できます。

T2 メールが初めて表示された時刻

受信トレイでそのメールを初めて確認した時刻を記録します。メール本文の日付や送信側のDateフィールドを代わりに使わないでください。受信システムへの到着時刻とは限りません。

T3 コードの失効時点

送信側が示す有効期限と、実際にコードを送信した結果を分けて記録します。リクエスト・生成・送信のどの時点から計時するのか不明な場合は、「起算点未確認」と記し、推測で決めないでください。

T2−T1は「ユーザー側で初めて確認できるまでの時間」と呼ぶのが適切で、「SMTPの配信所要時間」とするのは避けましょう。また、期限切れの表示が示すのは通常、その送信が受け付けられなかったことだけです。コードが失効した正確な秒数までは特定できません。

準備：1つのセッションと完全なメールアドレス

開いたら、使い捨てメールの受信トレイ実際に生成された完全なメールアドレスをコピーし、登録フォームに余分な空白や文字の欠落がないか確認します。ホーム画面に表示されるMicrosoftとUberのメールはデモ用で、あなたが開始したテストの結果ではありません。配信記録には含めないでください。

• 登録ページのタブは1つだけにし、セッションをAとして記録します。スマートフォンから同じ操作を同時に行わないでください。
• 使い捨てメールの残り時間を確認し、待機・検証・記録の整理に使える余裕を確保します。
• テスト条件が変わる自動入力や自動再試行を無効にし、待機時間の上限をあらかじめ決めます。
• 環境、ブラウザー、今回のテスト目的を記録します。共有シートに完全な認証コードやアクセス情報を保存しないでください。

Fwdskyで新しく作成した一時メールボックスの有効時間は初期設定で3時間です。延長に成功するたびに3時間追加されます。表示されるカウントダウンを基準にしてください。これはメールボックスの利用可能時間であり、送信元サイトの認証コードの有効期限ではありません。まず利用期限を確認して、テストに使い捨てアドレスが適しているか判断しましょう。

最初は1回だけ送信し、基準を記録する

最初のリクエストにA-R1と番号を付けます。送信ボタンを1回だけ押し、T1と画面の応答を記録します。メールが届かなくても、計画した時間だけ待ち、すぐに連打しないでください。メールを確認したらT2、件名、照合に使える情報を伏せたうえで記録し、同じ登録ページでコードを送信します。送信時刻と元の結果カテゴリも記録してください。

以下は架空の記録例です。時刻はすべて同じ日の同じ端末で記録したものです。実際のテストでは自分のデータを入力してください。

このテストから言えるのは、「メールが初めて表示されるまで12秒かかり、その後の送信が1回成功した」ことです。「メールサーバーの配信に正確に12秒かかった」とは断定できません。有効期限のルールをテストする場合は、別のテストとして実施してください。一度使用に成功したコードだけでは、タイムアウトによる失効を単独で判定できません。

7秒ごとの確認は、配信時間を測るストップウォッチではない

Fwdskyの受信トレイは7秒ごとに自動で確認されます。前回の確認時にはメールがなく、次の確認時にメールが表示された場合、画面上で表示状態が変わったのは2回の確認の間かもしれません。画面だけでは、その正確な秒数は分かりません。リクエスト処理時間や人の反応、ブラウザーのバックグラウンドでの動作制限も観察誤差の要因になります。

手動で更新した場合も記録する

確認の合間に手動で更新した場合は、その時刻を記録してください。すでに届いていたメールを早く確認できる可能性はありますが、送信側の配信が速くなるわけではありません。一方は手動で更新し、もう一方は自動確認を待つという異なる条件のテストで、数秒の差をそのまま比較するのは避けてください。

推奨：「14:00:12に画面でメールを初めて確認。確認中は自動チェックを使用。」避ける表現：「メールは14:00:12にSMTPへ正確に到着。」

認証コードの配信を正確にテストするには、許可された環境でリクエストID、キュー投入時刻、送信記録、受信ログを関連付け、各システムの時計が同期されていることを確認します。ユーザー側の画面から得られるのは、その証拠の一部だけです。

2回目で、再送ルールをテストする

まず基準となる結果を保存してから、2回目の記録を作成します。最初のリクエストをB-R1、送信元の再送待機時間を守ったうえで再送したものをB-R2とし、それぞれクリック時刻、受付時刻、メールが初めて表示された時刻を記録します。再送後の認証コードは新しいものに変わる場合も、同じコードが再利用される場合もあります。数字が変わったかどうかだけで、実際に送信されたかを判断しないでください。

「新しい／古い」は一覧の位置ではなくリクエストに紐付ける

一番上のメールが必ず最後のリクエストに対応するとは限りません。非同期処理は順不同で完了することがあります。本文にリクエストIDなど信頼できる照合情報がなければ、「紐付け未確認」と記録してください。バックエンドへのアクセス権があればログで照合し、証拠がなければ無理に原因を特定しないでください。

• まず製品の仕様を確認します。再送すると旧コードはすぐ失効しますか。それとも短時間は併用できますか。
• 旧コードと新コードを検証する際は、認証成功によってコードが消費されたり、チャレンジが終了したりする可能性を考慮し、必要に応じて別々のテストで確認してください。
• 認証結果を毎回記録し、試行回数の制限を守ってください。失効時刻を探るためにコードを何度も試さないでください。

画面の応答が「無効または期限切れ」のみの場合は、そのまとめられたカテゴリのまま記録します。タイムアウト、使用済み、再送による置き換え、セッション不一致などが考えられるため、すぐに「新しいコードが古いコードを置き換えた」とは書けません。

複数タブと遅れて届いたメールは分けて扱う

タブAで登録を開始し、タブBでログインを開始した場合、同じメールアドレスを使っていても別の認証チャレンジに対応する可能性があります。メールと照合する前に、記録上でページ・用途・セッションを区別してください。BのコードをAに入力して失敗しても、メール配信の問題とは限りません。

テストを終えた後に古いメールが届いた場合は、「遅れて到着。前のテスト回に属するか、紐付け未確認」と記録し、元のリクエスト時刻を保持してください。計時をリセットしてはいけません。条件を分離できる場合は、次のテスト回で別のアドレスを使えます。ただしアドレスを変更すると古いメールボックスが削除されるため、以前のリクエストに対する後続メールは観察できなくなります。

ブラウザーで共有されているログイン状態によって、2つのタブが互いに影響することもあります。独立したセッションが必要な場合は、許可された分離テスト環境を使い、環境の変更を記録してください。タブをもう1つ開くだけでは、独立したセッションにはなりません。

失敗を分類してから、次の対応を決める

「メールが届かない」だけでは、結論として不十分です。どの段階で失敗したかを明記すれば、誤った箇所で何度も更新するのを防げます。

使い捨てメールボックスの利用期限、認証コードの有効期限、ページの再送待機時間は、それぞれ別のタイマーです。メールボックスを延長しても、発行済みの認証コードの期限は延びません。受信トレイを更新しても、失効したコードは再び有効になりません。

終了後は秘密情報ではなく、結果を保存する

環境、リクエストID、時刻、待機方法、結果カテゴリを、機密情報を伏せて保存します。スクリーンショットでは完全なメールアドレス、コード、セッションID、個人的な本文を隠してください。受信トレイへのアクセストークンをチケット、チャット、共有ドキュメントに載せないでください。テストメールを削除しても、第三者サービスで作成したアカウントは削除されません。

テストが終わったらメールを削除し、テスト対象システムの手順に従ってテストアカウントを削除するか、長期利用できるアドレスに変更してください。使い捨てアドレスをパスワード再設定、返金、安全通知に使い続けないでください。ブラウザーデータを消去しても、サーバー上のデータが削除されるわけではありません。詳しくはプライバシーポリシーをご覧ください。

次のステップ：受信目的に合ったアドレスを選ぶ

登録メールを1回だけ確認するなら、受信トレイに戻って次のテストを始められます。通知やアカウント復旧、注文後のメールを継続して確認する場合は、管理下にある長期利用のメールアドレスを使うか、ログインして転送用アドレスを作成してください。エイリアスは届いたメールを実際のメールアドレスに転送しますが、アカウントへのアクセスとエイリアスの状態は適切に管理する必要があります。

まだ迷っている場合は、まず使い捨てメールとメールエイリアスの違いをご覧ください。大切なのはテストを早く終えることではなく、次に確認する人が「何を確認できたか」と「何の証拠がまだないか」を把握できるようにすることです。