開発者・QAへ戻る
メールQAは受信先の分離から始まる
一時受信箱でメールフローをテストし、テストノイズを増やさない方法
新しい受信先で実際のメールを観測し、送信、配信、本文、環境、最終状態を分けて検証することで原因を追えるテストにします。
読了目安 8分
良いメールテストは「何か届いた」で終わりません。クリーンな受信先を用意し、既知の操作を一度だけ起こし、その操作に対応するメールを待ち、最後にアプリ側の状態まで確認します。一時受信箱の価値は受信先を使い捨てにできる点にあり、全シナリオで共有すればその利点は失われます。
フローを診断可能な層に分ける
| 層 | 確認すること | 典型的な失敗 |
|---|---|---|
| Trigger | 送信イベントが作られたか | UI成功だがjobなし |
| Delivery | 正しい宛先に届いたか | 宛先・queue・routing違い |
| Message | 送信者、件名、本文、actionは正しいか | 古いtemplateやcode |
| Action | link/codeで状態が変わるか | mailは正しいがbackendが壊れる |
| Cleanup | 次のrunが独立しているか | 共有状態 |
再現可能な手動フロー
- 1
新しい受信先を作る
新規登録やrecencyが重要なら特に分離します。
- 2
1つの操作だけ起こす
観測前に複数メールを生成しません。
- 3
文脈全体を確認する
宛先、送信者、件名、locale、URL/code、時刻を見ます。
- 4
ユーザー操作を完了する
link/code使用後のアプリ状態までassertします。
ブラウザ分離だけでは受信箱は分離されない
PlaywrightとCypressはブラウザ状態を分離しますが、外部メールボックスは別の共有状態です。同じ宛先を使えば並列テストは衝突できます。
受信先もuserやbackend fixtureと同じテストデータとして所有させます。
手動QAとCI自動化を混同しない
Web受信箱は探索QAに向きます。CIが受信先作成やメッセージ取得をコードで必要とするなら、その機能を持つtest harnessを使い、存在しないMailOnce公開APIを前提にしません。
一時受信箱は共有状態を減らすときに最も役立ちます。1シナリオに1受信先、1trigger、1つの期待結果を持たせると失敗の説明が明確になります。
手動メールQA用のクリーンな受信先が必要ですか？
MailOnceで、個人の受信箱をテストデータとして使わずに、登録、OTP、マジックリンク、パスワード再設定、通知メールを確認できます。
使い捨てメールを作成参考資料と追加情報
テスト指針の根拠として使用したセキュリティ資料とテストランナーの一次ドキュメントです。
次のテストへ
同じメールテスト領域にある次の境界を確認します。