テスト用の一時メール：開発者とQAチームが登録フローを確認する方法

メールを送るプロダクトでは、誰かが新しいアドレスで何度も何度も登録しなければなりません。開発者は自分のGmailにプラス記号を付けて使い、QAテスターは捨てアカウントをスプレッドシートで管理し、プロダクトマネージャーは同僚の受信トレイを借ります。新規ユーザーが本番やステージングのメール環境から実際に何を受け取るかを確認する、という1つの作業に関しては、テスト用の一時メールアドレスがどれよりも速い方法です。

私たちはPureTempMailのメールサーバーを運用しているので、以下の制限は推測ではなく実際の設定値です。このガイドでは、テスト計画の中で公開受信トレイがどこに位置づけられるか、5分でできる手動テストの手順、私たち自身の登録メールに使うチェックリスト、そして別のツールを使うべきケースを取り上げます。

テスト手段の中での一時受信トレイの位置づけ

テストアカウントにアドレスを用意する一般的な方法は5つあります。多くのチームは、同じリリースの異なる段階で、そのうち2つか3つを使い分けることになります。

一時受信トレイは、ほかの手段が埋められない隙間で役に立ちます。本物のメールプロバイダーが送った本物のメッセージが、自分の管理下にないドメインに届き、数秒でブラウザに表示される、という点です。どこかにまた新しいアカウントを作ることなく、新規顧客が目にするものに最も近い状態を確認できます。

PureTempMailを使った手動テストの手順

登録フローを手作業で確認するときにおすすめする手順です。1回あたり5分ほどかかります。

1. 1

   テストユーザーごとに新しいメールボックスを開く

   別のブラウザウィンドウでPureTempMailを開きます。読み込むと新しいアドレスが作成されます。メールボックスはブラウザごとに記憶されるので、テストユーザーごとに新規を押すか、2人のテスターが1台のマシンを共有する場合はプライベートウィンドウを使ってください。

2. 2

   テストケースの横にアドレスを記録する

   使う前に、アドレスをテストケースやチケットに貼り付けておきます。後でテスターから再設定メールが届かなかった理由を聞かれたとき、どのメールボックスに送ったかを知っておく必要があります。

3. 3

   登録を実行し、送れるメールをすべて送らせる

   フォームを送信したら、新規ユーザーが最初のセッションで発生させうるメールをリクエストします。確認メールの再送、パスワードを忘れた場合、マジックリンクでのログイン、メールアドレス変更のリクエストなどです。それぞれが別のテンプレートで、個別に壊れる可能性があります。

4. 4

   再読み込みせずに受信トレイを見守る

   新しいメールは、私たちのサーバーが受け付けた瞬間にライブ接続でページにプッシュされます。そのため、メッセージが表示された時刻は実際の配信時刻に近くなります。それぞれにかかった時間を記録してください。配信経路については仕組みで説明しています。

5. 5

   各メッセージを両方の表示で開く

   HTMLで読んだ後、テキストに切り替えます。テキスト表示は、一部のメールソフトやスクリーンリーダーが代わりに使う表示で、テキストパートの欠落や読めないコードが最初に見つかる場所です。すべてのリンクをクリックして、どこに移動するかを確認してください。

6. 6

   フローに時間がかかるなら延長する

   ステップメール、承認待ち、2日目のリマインドなどには、もっと時間が必要です。+1時間を押すと、タイマーが1時間にリセットされます。メールボックスの作成から24時間までは、これを繰り返せます。

7. 7

   期限切れにしてからバウンスをテストする

   期限切れ後、私たちのサーバーはそのアドレス宛てのメールをSMTPの段階で、"No such mailbox"という恒久エラーで拒否します。もう1通そのアドレスに送り、アプリやメールプロバイダーがハードバウンスとして記録し、そのユーザーへの送信を止めることを確認してください。

登録メールのテストチェックリスト

どのプロダクトでも、リリース前に登録メールで確認したい項目です。どれも本物の受信トレイなら見つけやすく、コードレビューでは見落としやすいものです。

• 確認コードまたはリンク。届くこと、コードがテキストで読めること、リンクが1回だけ使えること、2回目のクリックでエラーページではなくわかりやすいメッセージが出ること。
• マジックリンクとワンタイムコード。新しいリンクで古いリンクが無効になること、期限切れのリンクで次に何をすべきかが説明されること、別のブラウザでリンクを開いたときに意図どおりに動くこと。
• パスワード再設定。どのアカウント向けのメールかが書かれていること、リンクに有効期限があること、未登録のアドレスで再設定をリクエストしても、そのアドレスにアカウントがあるかどうかがわからないこと。
• ウェルカムメールとステップメール。最初の1通が確認の前ではなく後に届くこと、確認を済ませていないユーザーには後続のメールが送られないこと。
• HTMLパートとテキストパート。両方が存在し、同じ内容であること、重要な情報が画像の中だけにないこと。私たちのHTML表示では外部画像が読み込まれるので、そこで画像を確認し、テキスト表示で画像なしのメッセージを確認できます。
• 添付ファイル。請求書やPDFが、適切なファイル名とコンテンツタイプで届くこと。テスト用のファイルは1メッセージあたり1 MB未満にするか、ダウンロードリンクを送ってください。そのほうが実際のユーザーにも親切です。
• リンク先。本番のメールにlocalhost、社内ホスト名、ステージングのドメインを指すリンクがないこと、トラッキング用のリダイレクトが正しいページにたどり着くこと。
• 配信停止ヘッダー。マーケティングメールやステップメールに有効な配信停止リンクがあり、大量送信者の場合はRFC 8058で定められたワンクリックのList-Unsubscribeヘッダーがあること。これはGoogleの送信者ガイドラインで大量送信者に義務づけられています。再設定メールのようなトランザクションメールは、配信停止によって止められるべきではありません。
• 配信時間。確認メールが1、2分以上かかると、ユーザーは離れていきます。遅い場合は、アプリがほかのジョブの後ろにメールを並べていないか、プロバイダーが新しい送信者を制限していないかを確認してください。
• 自社のレート制限。再送ボタンを連打してみてください。アプリは回数を制限してユーザーに待つよう伝えるべきで、コードを10通送ったり、何も言わずに失敗したりしてはいけません。
• アドレスの再利用。1つのセッション内で同じアドレスで2回登録し、2回目を確認します。「登録済み」とわかりやすく案内され、2つ目のアカウントが作られないこと。
• 使い捨てドメインのルール。一時アドレスをブロックしているなら、エラーメッセージがわかりやすいこと、そして誤って本物のプロバイダーまでブロックしていないことを確認してください。詳しくは後述します。

当サービスの制限と、テストへの影響

私たちのサーバーの実際の設定値です。テストはこれを前提に計画してください。

有効期間

作成から1時間。+1時間で1時間にリセットでき、作成から24時間まで延長できます。1回のセッションには十分ですが、次のスプリントで使い回すテストアカウントには足りません。

メッセージ

1つのメールボックスにつき最大50通、5 MBまで。どちらかの上限に達すると新しいメールは拒否されるので、1つのアドレスに向けた負荷テストはすぐにカウントが止まります。テストユーザーごとに新しいメールボックスを開いてください。

メッセージサイズ

1通あたり添付ファイルを含めて最大1 MB。保存されるのは最初の10個の添付ファイルだけです。

受信専用

このアドレスからは送信も返信もできません。サポートチケットのやり取りのように、ユーザーがメールで返信する必要があるフローは、ここでは最後までテストできません。

ドメイン

すべてのアドレスで同じ1つのドメインを使います。既知の一時ドメインをブロックしているプロダクトなら、私たちのドメインもブロックされます。その挙動をテストしたいときには好都合です。

新しいメールボックス

1つのIPアドレスから1分あたり5個まで。同じオフィス回線を使うQAチームは、この枠を共有することになります。

削除

期限切れ後、5分ごとに実行されるクリーンアップが、メールボックスとそのメッセージ、添付ファイルを削除します。バグ報告の証拠が必要なら、タイマーが切れる前にスクリーンショットを撮ってください。

自動化

メールボックスにスクリプトからアクセスするための公開APIはありません。PureTempMailはブラウザを見ている人のために作られているので、自動テストスイートには後述のツールが適しています。

テストメールのSPF、DKIM、DMARCを確認する

きれいに表示されるメッセージでも、認証に失敗して実際のユーザーの迷惑メールフォルダに入ってしまうことがあります。確認するには、同じメールをGmailのメッセージのソースを表示のように生のソースを表示できるメールボックスに送り、ヘッダーを私たちのメールヘッダー解析ツールに貼り付けます。SPF、DKIM、DMARCに合格したか、Reply-Toが別のドメインになっていないかがわかり、配信が遅れた場所も表示されます。解析はブラウザ内で行われるので、ヘッダーが私たちに送られることはありません。

自社の使い捨てドメインのブロックをテストする

登録フォームに使い捨てメールのチェックを追加しながら、本物の一時アドレスで一度もテストしていないチームは少なくありません。一時受信トレイは、まさにうってつけのテスト入力です。

• 文言を確認する。拒否メッセージでは、代わりに何を使えばよいかを伝えるべきです。たとえば「個人用または仕事用のアドレスを使用してください」などです。ただの「無効なメールアドレス」では、誠実なユーザーがありもしない入力ミスを探すことになります。
• 誤検知を確認する。地域の小規模なプロバイダーや、企業の独自ドメインのアドレスで試してください。パターンで照合するブロックリストは、ときどきそれらを巻き込みます。
• すべての入口を確認する。登録フォーム、メールアドレス変更の設定、招待、APIに同じルールを適用すべきです。そうしないと、忘れていた経路が使われるだけです。
• そもそもブロックが必要か判断する。Webサイトが使い捨てメールをブロックする理由の記事で、ブロックを正当化するコストと、誠実なユーザーを失うだけになるケースを解説しています。

公開の一時受信トレイが適さない場合

次のような場合は、別の手段を使ってください。

• 本物の機密情報や顧客データを含むもの。本番のトークン、本物の請求書、管理者への招待など。チームだけが読めるサンドボックスを使ってください。
• 自動テストとCI。開発環境とCIではMailpitのようなローカルキャッチャーにアプリを向け、デプロイ済みの環境に対してテストを実行する必要があるときはMailtrapやMailosaurのようなホスト型サンドボックスを使います。以前からあるローカルキャッチャーのMailHogはもうメンテナンスされておらず、Mailpitが一般的な代替です。
• 本物のユーザーデータのコピーがあるステージング環境。そこでの問題はコピーされたデータそのものです。データを消去し、ステージングのメールはキャッチャーに流して、テストが本物の顧客にメールを送らないようにしてください。
• 残しておく必要があるテストアカウント。営業用のデモアカウントやアプリストア審査用のアカウントには、翌月も使えるアドレスが必要です。チームのメールボックスでプラスアドレスを使うか、自社のテストドメインでキャッチオールを使ってください。
• 絶対に配信されてはいけないフィクスチャ。シードデータや単体テストには、example.comなどの予約済みドメインや、RFC 2606で確保されている.testトップレベルドメインを使ってください。これらへのメールは、仕様上どこにも届きません。

出典

• GitHubのMailpit。開発者向けのメールテストツールとAPIで、MailHogからの置き換えについての説明もあります。
• Mailtrap Email Sandboxのドキュメント。
• GitHubのMailosaurクライアントライブラリ。
• RFC 8058、Signaling One-Click Functionality for List Email Headers。
• Google、メール送信者のガイドライン。
• RFC 2606、Reserved Top Level DNS Names。
• メールボックスの有効期間、サイズと件数の上限、レート制限、期限切れ後のSMTPでの拒否、クリーンアップのタイミングは、PureTempMail自身のサーバー設定に基づいています。よくある質問にもまとめています。