期限をテストするなら、
受信だけでは不十分

メールが1通届いても、確認できたのは流れの途中まで

アドレスをコピーしてメールを送り、認証コードが届く。これで確認できるのは、その時点で受信できたことだけです。自動削除メールにはもう一つの約束があります。有効期限後は古いアドレスが使えなくなり、以前の認証情報でもメールを読めなくなること。そして、新着メールが届いても、閲覧中のメールが勝手に切り替わらないことです。

そのため、使い捨てメールのテストでは、スクリーンショットに「1通届いた」と記録するだけでなく、ライフサイクル全体を確認する必要があります。まずは使い捨てメールの受信トレイから始め、自分で管理している送信元メールアドレスと架空の内容を使ってテストしましょう。サンプルを作るために本物のアカウントを登録したり、銀行の認証コード、注文の詳細、顧客情報をテストデータに使ったりしないでください。

まず、アドレス・メール・ブラウザー認証情報の失効条件を明確にする

まず、3つの対象を区別しましょう。アドレスは受信先を決め、メールはサーバーに保存される内容、ブラウザー認証情報は誰が受信箱を読めるかを決めます。この3つは同じものではありません。画面に本文が残っていても、アドレスがまだ受信可能とは限りません。端末に認証情報が残っていても、サーバーがそれを受け付けるとは限りません。

FadeInboxのホームで作成した新しいアドレスは、初期状態で3時間有効です。延長に成功すると、さらに3時間延長されます。アドレスを変更すると、新しい3時間有効のアドレスが作成され、古い受信箱は削除されます。実際の期限は、サーバーからの応答と画面のカウントダウンで確認してください。有効期間の計画ではルールを説明しています。テスト記録には、今回実際に確認した値も記載しましょう。

期限切れ後に新しいアドレスが自動生成される場合は、新旧それぞれの結果を分けて記録してください。新しい受信箱で正常に受信できても、それだけでは古い受信箱が無効になった証拠にはなりません。使い捨てメールは「読んだらすぐ消える」ものではありません。このテストでいう削除の境界は、有効期間の終了または明示的な削除操作です。

再現可能なサンプルを用意する：固有のテストIDとプレーンテキスト・HTMLの本文

今回のテストには、個人情報を含まないIDを付けます。たとえば、 FX-261014-A件名は順に、 FX-261014-A / 01 / TEXT と FX-261014-A / 02 / HTMLとします。このIDで記録をひも付けます。完全な受信アドレスやアクセス認証情報をIDに含めないでください。

2通のメールにそれぞれ役割を持たせる

• プレーンテキストメール：段落分けした文章をいくつか、長い単語を1つ、架空の6桁の数字を入れ、改行、狭い画面での折り返し、選択・コピーを確認します。
• HTMLメール：自作のヘッダー、見出し、認証コード欄、十分な長さの本文を使い、プレーンテキスト版も添えます。
• 共通の注意点：予約済みのサンプル用ドメインを使い、本物のログインリンク、トラッキングピクセル、外部の情報収集フォームは埋め込まないでください。

認証コードメールの表示では、数字が途中で切れていないか、本文と背景が読みやすいか、狭い画面で横スクロールが発生しないかを確認します。HTMLメールを隔離して表示する場合、受信トレイのボタン用スタイルを引き継いではいけません。外部画像がブロックされても、それだけで不具合とは限りません。重要なのは、本文の主要な情報を読めることです。

ホームに表示されるWhatsAppとLinkedInのサンプルメールは、画面の見方を理解するためのものです。メールの送信・受信経路が正常に動作する証拠にはなりません。確認には、自分で送信した実際のテストメールが必要です。届かない場合は、まず受信診断を確認してください。遅延と重複受信が混同されるため、立て続けに再送しないでください。

カウントダウンの境界：フォアグラウンド・バックグラウンド・ページ再表示で確認すること

作成後の期限を記録し、カウントダウンを観察します。ページを表示中は秒単位で更新され、毎回のポーリング時にだけ進む状態にならないことを確認してください。期限が近づいたら、「期限前」「期限を過ぎた時点」「状態の更新完了」の3つの時刻を記録します。画面の更新に多少の遅れが生じることはありますが、無期限に利用可能な状態が続いてはいけません。

バックグラウンドにしても、有効期間は一時停止しない

タブを数分間バックグラウンドにしてから戻ります。ブラウザーはタイマーを間引くことがあるため、バックグラウンドで毎秒コードが実行される必要はありません。確認すべきなのは、ページに戻ったときに実際の期限に合わせて状態が補正されることです。離れる前の残り秒数から単純にカウントダウンを再開し、アドレスが実際より長く使えるように見えてはいけません。

ページを開き直し、「時間の再付与」ではなく復元を確認する

同じブラウザーを通常どおり閉じてからページを開き直します。有効な古い受信箱の期限が維持され、理由なく3時間にリセットされないことを確認してください。プライベートブラウズ、サイトデータの削除、別の端末は条件が異なります。別のテストケースとして記録し、復元の失敗と誤判定しないでください。

パソコンの時計を変更して、サーバー側の期限切れを再現しないでください。許可された短時間テスト環境がなければ、実際に時間を置いて確認します。他のテストを先に進めてもかまいませんが、最終的には期限の境界を実際に越える必要があります。

延長とアドレス変更は別の操作：有効期間と旧アドレスの状態を個別に確認する

延長ではアドレスと既存のメールを維持し、期限だけを変更します。操作前の期限を記録してから一度クリックし、成功の表示が出るのを待ち、新しい期限が約3時間延びたことを確認してください。操作にかかった時間を無視して、クリック前後の「残り秒数」だけを単純に引き算しないでください。

アドレス変更はその逆です。新しいアドレスが作成され、新しい有効期間が始まり、古い受信箱とメールは削除されます。まず延長の確認を終えてからアドレスを変更し、新しいアドレスの有効期間が古い受信箱の延長分を引き継がず、新たに3時間から始まることを確認してください。

• 延長に成功：アドレスは変わらず、古いメールも読める。期限が延長され、画面に成功の表示が出る。
• アドレス変更に成功：アドレスが変わり、古いメールは一覧から消える。選択状態や本文が新しい受信箱に引き継がれない。
• 操作に失敗：成功と表示しない。有効な新しい受信箱を取得する前に、まだ使える古いアドレスを破棄しない。

ネットワークが遅いときは、ボタンを繰り返しクリックしないでください。画面が処理中のままなら、まず処理の完了を待って結果を確認します。旧アドレスが無効になったかどうかも、送信側にバウンスメールが返ったかだけで判断できません。相手側でメールがキューに入ったり、再試行されたり、バウンスメールが送られなかったりする場合があります。

ポーリングで閲覧を中断させない：テストメール2通で選択状態とスクロール位置を確認する

まず、長めのHTMLテストメールを開いて本文の途中までスクロールし、目印となる一文を覚えておきます。次に自分の送信済みフォルダーから2通目を送り、新しいメールが一覧に表示されるのを待ちます。一覧は更新されても、現在の件名、選択中のメール、本文、スクロール位置は変わらないはずです。

少なくとも2回ポーリングされるまで待ってから、手動でもう1通に切り替えます。数秒ごとに1通目へ自動的に戻る、本文が一瞬ちらつく、スクロール位置が先頭に戻る場合は、一覧の更新時に閲覧領域まで再生成されている可能性があります。メールが「既読」になったことを、自動で切り替える根拠にしてはいけません。

スマートフォンでも確認する

実際のメールを開くと、独立した閲覧画面が表示されるはずです。戻る操作と削除操作にはいつでもアクセスでき、背面の画面が一緒にスクロールしてはいけません。新着メールで更新されるのは一覧だけで、閲覧画面が自動で開いてはいけません。一覧に戻った後も、閲覧中だったメールに選択マークが残る必要があります。メールの自動選択と、ユーザーが開く操作は別のイベントです。

最後に現在のメールを削除し、別のメールに切り替わるか、わかりやすい空の状態が表示されるかを確認します。すべて削除した後は、一覧と詳細の両方に見出しや説明が表示され、古いメールのヘッダーが残ってはいけません。

期限後も古い本文が表示される場合：画面のキャッシュとサーバーからの再取得を区別する

期限切れ後に古い文章が表示されても、すぐに「サーバーから削除されていない」と判断しないでください。ブラウザーに読み込まれた本文がメモリー上に残っている可能性があります。もう一つは、アプリが古いメールの詳細を再取得できている場合です。前者は画面表示の消去に関する問題、後者はアクセス権やデータ保持の境界に関わる問題です。どちらも記録は必要ですが、証拠は異なります。

1. 期限切れ後の画面状態を記録します。古いアドレスはまだ利用可能と表示されていますか。古い本文は画面から消えましたか。
2. ページを更新するか、古いメールを開き直して、すでに表示されている内容が残っているだけなのか、新たに詳細を取得したのかを確認します。
3. 開発者ツールの使用経験がある場合は、自分のテスト用受信箱でリクエストの状態とレスポンス内容を確認します。スクリーンショットを撮る前に、クエリパラメーターと認証情報を隠してください。

ネットワーク切断、タイムアウト、または一度のリクエスト失敗だけでは、削除が成功した証拠になりません。サーバーが古い受信箱へのアクセスを明確に拒否したこと、または該当する期限切れ状態を返したことを確認する必要があります。古い認証情報が使えなくなったことから確認できるのは、そのアクセス経路で取得できなくなったことだけです。フロントエンドのテストだけでは、バックアップ、ログ、すべての保存データの複製が物理的に消去されたことまでは証明できません。

ページがすでに新しい受信箱に切り替わっている場合は、古い受信箱の確認結果を分けて記録してください。新しい認証情報に差し替えてから「古いメールが見つからない」と判断するのはやめましょう。データの取り扱い範囲については、プライバシーポリシーをご確認ください。

テスト結果は、機密情報を含むスクリーンショット集ではなく、確認記録として残す

適切な記録なら、同僚が同じ手順を再現できても、あなたのメールボックスにアクセスすることはできません。テストID、ブラウザーのバージョン、端末の幅、タイムゾーン付きの日時、手順、期待結果、実際の結果を記録しましょう。アドレスは代わりの識別子で表し、認証コードには架空のサンプルだけを使います。

テスト：FX-261014-A
環境：ブラウザーのバージョン / OS / ビューポート幅
ケース：長いメールを読んでいる間に2通目を受信
手順：02を開く → 段落の目印までスクロール → 01を送信 → ポーリングを2回待つ
期待結果：新しい行が表示される。現在のメール、選択状態、スクロール位置は変わらない
実際の結果：実行後に記入。「合格」とあらかじめ決めない
証跡：個人情報を隠したスクリーンショットのID / 確認日時とタイムゾーン
結論：合格 / 不合格 / 要再確認

ネットワークのエクスポートファイルをそのまま共有しないでください。一時受信箱のトークン、アカウントのトークン、メール本文、添付ファイルのダウンロードURLが含まれている可能性があります。診断資料の共有が必要な場合は、チームのルールに従って情報を伏せ、アクセス範囲を制限してください。判断に迷ったら、元のリクエストではなく手順とエラー発生時刻を先に共有しましょう。

「要再確認」も有効な結論です。送信側でまだ配信されていない、テスト中にネットワークが切断した、一時メールの期限切れ時にパソコンがスリープしていたなどの条件があれば、記録に明記してください。表を整えるために無理に「合格」と記入してはいけません。

テスト後の後片付けと、一時メールだけでは証明できないこと

自分で送信したサンプル、ダウンロードした添付ファイル、ローカルの診断ファイルを削除し、テスト中に外部アカウントや購読を誤って作成していないか確認します。保管が必要なテスト記録は、メールの認証情報とは別に保存してください。アドレスを削除しても、送信済みフォルダーのコピーや外部プラットフォームのデータは削除されません。

このテストケースで確認できるのは受信、閲覧、無効化の境界です。すべての送信元が使い捨てアドレスを受け付けること、メールが遅延しないこと、内容が完全に匿名であること、実際のアカウントをいつでも復元できることまでは証明できません。重要なアカウントには、自分で直接管理するメールアドレスを使いましょう。通知を継続してテストする場合は、長期転送エイリアスも利用できますが、恒久的なバックアップの代わりにはなりません。

どちらのアドレスを使うか迷ったら、まず使い捨てメールとエイリアスの違いをご覧ください。テストを終える際に残すべきものは、まだ開ける古いメールではなく、再現可能な状態の境界と明確な結論です。