開発者・QAへ戻る
メール到着はゴールではなく中間点
登録メール確認をフォーム送信からVerified状態までテストする方法
新しいアドレス、現在の確認メール、確認操作、最終的なverified状態までを1つの状態遷移として検証します。
読了目安 8分
確認メールが届くだけで登録テストを成功にすると、間違った環境へのURLやbackendの未更新を見逃します。1つの新しいidentityをフォームから最終verified状態まで追い、そのメールが現在の登録試行に属することを確認する必要があります。
状態遷移全体を確認する
- 1
未登録アドレスから始める
duplicateやresendの挙動と混同しないためです。
- 2
登録を1回だけ行う
identity、locale、environmentを記録します。
- 3
現在のメールを特定する
宛先、時刻、host、code/tokenを照合します。
- 4
公開された確認フローを使う
DBを直接verifiedにしません。
- 5
最終状態をassertする
アクセス制御も本当に変わるか確認します。
重要なnegative case
| Case | 確認 | 防ぐ失敗 |
|---|---|---|
| 古いメール | 新しい試行を検証しない | false positive |
| 環境違い | stagingとproductionを分離 | host混同 |
| 期限切れ | 安全に失敗し再試行できる | 遅延利用 |
| 再利用 | 仕様どおりの挙動 | replay |
verifiedはidentity state
OWASPはメール検証をidentity systemの一部として扱い、Auth0もemail_verifiedによるアクセス制御を示しています。「メールを確認してください」というUIは最終assertではありません。
backend stateを確認することで、見た目が正しいメールと壊れた遷移を分けられます。
失敗時に残す証拠
- 宛先と環境
- 登録直後のresponse
- 送信者・件名・時刻
- secretを除いたverification host
- 前後のaccount state
登録確認テストは、正しいidentityが未確認から仕様どおりのverified状態へ移ったときに完了します。メールはその遷移の一部です。
手動メールQA用のクリーンな受信先が必要ですか？
MailOnceで、個人の受信箱をテストデータとして使わずに、登録、OTP、マジックリンク、パスワード再設定、通知メールを確認できます。
使い捨てメールを作成参考資料と追加情報
テスト指針の根拠として使用したセキュリティ資料とテストランナーの一次ドキュメントです。
次のテストへ
同じメールテスト領域にある次の境界を確認します。