登録用の認証コードをテストする場合、正常に完了する一連の操作だけでは、再送時の状態遷移に問題がないとは言えません。まず「最新のコードのみ有効」なのか「有効期間内のコードはすべて有効」なのか、仕様を確認してからテストケースを作成しましょう。旧コードが使えたからといって、すぐに不具合と判断すると、存在しない要件を検証している可能性があります。
テストごとに専用のアドレスを用意する
まず一時テスト用メールボックスから新しいアドレスを取得し、現在時刻と想定される有効期間を記録して、テスト対象システムの登録ページから最初のメールを送信します。メールが受信トレイに表示されたら、件名、到着時刻、有効期間に関するメール本文の説明を記録しましょう。テストが終わったら次のケースには新しいアドレスを使い、複数回のテストで届いた古いメールが同じ一覧に混ざらないようにします。
アドレス以外にも、入力されたメールアドレス、現在の認証コード、送信回数、次に再送できる時刻、ログインページの現在のステップなど、確認すべき状態があります。記録表にはイベントごとに「現在のメールアドレス」と「送信回数」の列を追加しましょう。必要に応じてテスト対象システムが返したリクエストIDも記録しますが、認証コード全体を公開しないでください。
待機時間：画面表示と実際の制限を確認する
ボタンにカウントダウンが表示された直後に連続でクリックしたり、キーボードで素早く送信したりして、メールが重複して届かないかを確認します。ブラウザーのタブ切り替えやページの再読み込み、オフラインからの再接続後に、画面上のカウントダウンとサーバー側の制限が同期しているかも調べましょう。ボタンがグレーアウトしても、連続送信を防げている証拠にはなりません。登録ページを開き直すだけで制限を回避できるなら、どれが新しいメールか分かりにくくなるほど大量のメールが届くおそれがあります。
1分ごとに再送できる仕様なら、待機時間の終了1秒前と終了1秒後にそれぞれ操作します。画面に表示された案内と実際に届いた新しいメールの数を記録し、「カウントダウンが1秒短い」だけの表示を通信の揺らぎと取り違えないようにしましょう。サーバー側の制限をテストする場合は、チームが許可したテスト環境を使い、実際の業務用アドレスに大量のメールを連続送信しないでください。
旧コードと新コード：仕様を決めてから判定する
最初のメールが届いたらコードをAとし、再送が可能になった時点でBを送信します。2通とも同じアカウント、同じ環境のものかを確認し、まずA、次にBを入力して、それぞれ認証できるか、画面にどのような説明が表示されるかを確認しましょう。最初のメールの到着が遅れた場合は、一覧の並び順ではなく送信順で新旧を判断します。到着順の復元には、登録メールのタイムライン記録方法を参考にしてください。
期待する結果は、次の3パターンに分けて記述します。新しいコードを発行すると旧コードは無効になる、各コードがそれぞれ有効期間内なら両方使える、再送後は最新のメールに記載されたリンクだけ使える、のいずれかです。チーム内でこれらのルールを混在させてはいけません。仕様が明確でない場合は、テストの合否を個人の推測に委ねず、まず要件を確認しましょう。
次に、わざと誤ったコードを入力するテストも行います。エラー表示では、入力ミス、期限切れ、送信頻度の制限、アカウント認証済みのどれに該当するかが分かるようにしましょう。公開用のスクリーンショットには、有効な認証コードや完全な認証リンクを残さないでください。テスト記録にはメールの通し番号と認証結果だけを残します。
メールアドレス変更後の再送：送信先を確認する
認証コードの入力画面でメールアドレスの変更を選び、別の専用テストアドレスに切り替えます。変更を送信したら、新しいメールが新アドレスだけに届くか、画面に新しいアドレスが表示されているか、旧アドレスに届いたコードで新しい登録フローを認証できないかを確認しましょう。旧アドレスに戻せる仕様なら、メールの件名だけで判断せず、状態遷移全体を確認します。
メールアドレスの変更後も旧アドレスに再送メールが届き続ける場合は、アカウントとの紐付け、キュー処理、またはフロントエンドに保存された項目に問題がある可能性があります。2つの受信アドレスを個人情報が分からない形で記録し、クリックごとの時刻と画面に表示された送信先を残せば、「キューの処理が遅れた」のか「誤った宛先に実際に送信された」のかを切り分けられます。
期限切れと重複送信も境界値テストに含める
有効期間の終了前と終了後に、それぞれAとBを入力し、コードの判定がメールの生成時刻、送信時刻、入力時刻のどれに基づくかを記録します。認証に成功したコードを再送信した場合は、仕様に応じて拒否するか、完了済みであることを明確に表示する必要があります。ブラウザーの戻るボタンを押しても、アカウントが再度有効化されてはいけません。登録ページにモバイル版とデスクトップ版など複数の入口がある場合は、待機時間と旧コードの状態がデバイス間で一致するかも確認しましょう。
一時テスト用アドレスは標準で3時間使えるため、1回の登録確認に適しています。回帰テストが翌日にまたがる場合や、送信済みメールを後から確認する必要がある場合は、まずテスト用メールボックスの有効期間プランナーを確認してください。長期保存が必要なら、転送エイリアスまたはチーム管理のテスト用メールボックスを使い、期限切れの一時アドレスに頼らないようにしましょう。
最後に再現可能なテスト記録をまとめる
「前提条件—操作—期待結果—実際の結果—確認できる証拠」を、1イベントにつき1行で記録します。前提条件には環境、アカウントの状態、すでに届いているメールを含めます。操作は送信、再送、メールアドレスの変更、認証コードの送信に分け、結果にはカウントダウン、受信先、エラーメッセージを記録しましょう。テスト全体では初回登録、重複登録、有効化もカバーし、登録フローテストチェックリストで抜け漏れを補えます。
再送に成功してもユーザーがログインできない場合は、どのコードをいつ入力し、その時点で画面にどのメールアドレスが表示されていたかを記録します。そうすれば、単に「認証コードがときどき無効になる」と伝えるのではなく、状態の不整合が起きた箇所を開発チームが調査できます。