登録フローのテスト

専用アドレスでメール経路全体をテスト

信頼できるメールテストは、認証コードが届くかを見るだけでは不十分です。トリガー条件、テンプレート、リンク、有効期限、遅延、再送まで確認してこそ、1回の成功を再現可能な品質評価に変えられます。

まずテスト範囲を明確にする

今回対象にするメールを列挙します。登録認証コード、確認リンク、ウェルカムメール、パスワード再設定、新しい端末への通知を含め、それぞれにトリガーとなる操作、想定される宛先、許容できる最大到達時間を記載します。

「メールが1通届いた」だけで合格にしないでください。件名、送信者、返信先、言語、リンク先、モバイル端末での読みやすさにも、明確な期待値を設定しましょう。

短期の連携テストでは、用途ごとに別の一時アドレスを作成すると、古いメールが新しい結果に影響しません。数週間の回帰テストや複数回の共同作業では、転送エイリアスを使うと同じIDを維持しやすくなります。

テスト記録の名前に、実在ユーザーの情報をそのまま使わないでください。個人情報を含まないケース番号を使い、対応するアドレスと環境を記録します。

クリーンなセッションから登録を開始し、送信ボタンを押した時刻とメールが届いた時刻を記録します。メールを開いたら、コードの形式、有効期限の説明、リンクのドメイン、遷移後のログイン状態を確認してください。

同じ認証コードは正常に使用した後で無効になる必要があります。古い確認リンクが新しいリクエストを上書きしてはいけません。ウェルカムメールは、プロダクトで定義した条件を満たした場合だけ送信し、ログインのたびに再送されないようにします。

誤った認証コード、期限切れコード、複数回の再送、アドレスの大文字・小文字、ネットワーク切断、連打を意図的にテストします。現在有効なコードがどれか、画面に明確な説明が表示されるか確認しましょう。

登録済みのアドレス、無効化されたユーザー、異なる端末からのログインも確認します。セキュリティ通知に認証情報全体を記載せず、内部エラーのスタックトレースもメールに含めないでください。

各ケースについて、環境、アドレス、トリガー時刻、到達時刻、テンプレートのバージョン、結果のスクリーンショットを記録します。共有前には認証コードやトークンなどの機密情報をマスキングし、添付ファイルも管理された場所だけに保存してください。

失敗は、「アプリが送信をトリガーしなかった」「送信サービスに拒否された」「配信が遅延した」「受信画面での表示に問題がある」に分類します。この分類なら、開発者が該当するログを直接確認できます。

一時アドレスは自然に期限切れになるのを待てますが、その前に必要な非機密の証跡を保存してください。転送エイリアスは一時停止または削除し、管理されないテストアドレスが長期間メールを受け取り続けないようにします。

本番環境に接続するテストは、必ず許可を得たうえで、データ最小化の要件に従ってください。大量のアカウントや実在ユーザーのIDを使ったり、制限を回避してカバレッジを増やしたりしないでください。