まず認証コードのライフサイクルを描く
ユーザーが送信ボタンを押すと、システムは認証コードを生成し、有効期限を記録して送信キューに入れ、認証を待ちます。メールが届いたことだけでは、その一部が成功したとしかいえず、コードがアカウント、有効期限、1回限りの使用ルールに正しくひも付いているとは確認できません。
テスト記録には、少なくとも対象メールアドレス、発火時刻、タスクID、到達時刻、認証結果を含めます。メールアドレスは隔離したテスト用アドレスを使い、個人の常用受信トレイを混在させないでください。
成功パスでは事実の整合性を確認する
メールに記載された6桁のコードが現在のセッションと一致し、有効期限の表示がサーバー側のルールと合っていることを確認します。コピー＆ペースト後は数字だけを受け付け、空白や画面上の書式で誤判定されないようにします。
認証に成功したら、フローは正しいページへ進み、「認証コードを送信しました」という固定表示が残らないようにします。同じコードを再び使った場合は、仕様どおり拒否するか完了済みの状態を維持し、2つ目のセッションを作成してはいけません。
再送はもう1通送るだけではない
再送ボタンには初回送信と同じクールダウンを適用し、カウントダウン中は無効化したまま残り秒数を表示します。ユーザーが戻ってメールアドレスを変更した場合、旧アドレスと新アドレスの認証コードを相互に使えないようにします。
新しいコードを発行した時点で旧コードが直ちに無効になるかを明確にします。テストでは2通のメールに到達順とコード値を記録し、ネットワーク遅延によって後から送ったメールが先に届く場合にも備えます。
期限切れの境界をテストする方法
期限切れの判定はサーバー時刻を基準にし、端末の時計を変更して再現しないでください。有効期限の中ほど、境界付近、境界を過ぎた後にそれぞれ送信し、無効、期限切れ、レート制限が明確に区別されるか確認します。
メールが届いた時点ですでに期限切れに近い場合は、発火、キュー投入、送信、受信の時刻を比較します。これにより、有効期限が短すぎるのか、送信キューに異常な遅延があるのかを判断できます。
レート制限と空のメールアドレス
メールアドレスが空欄または形式不正の場合は最初の段階で止め、バックエンドにコードを送信しないようにします。連続リクエストが上限に達したら、画面には日本語で案内を表示し、ユーザーが理解できる待機方法を示します。
レート制限が解除された後の再送では、古いログイン用トークンを引き継がないようにします。前回のログアウト情報が残っていても、認証コード入力の段階へ直接進めてはいけません。メールアドレスはセッションから復元できても、フローの状態は未認証の開始点からやり直します。
最小限のテスト証拠を残す
不具合の記録には、テンプレートのバージョン、タスクID、時刻、マスキングしたアドレス、エラー表示だけを残せば十分です。有効な認証コード、完全なログインリンク、実在する個人情報をスクリーンショットや共有ドキュメントに長期間残してはいけません。
修正後は新しいアドレス、新しい番号、新しい認証コードで再テストし、古いメールを誤って開かないようにします。成功、旧コード、期限切れ、レート制限の4グループの結果を確認してから、テスト用の入口を閉じます。