2026年 登録フローのテスト：認証コードが届いても合格とは限らない

1. まず範囲を決める：自分が管理する、または許可を得たフローだけをテストする

テストを始める前に、対象システム、環境、使用可能なアカウント数、送信頻度を明確にします。テスト環境と専用のテストデータを優先してください。本番環境でテストする場合は責任者の承認を得て、実際の顧客のアドレスは使わないようにします。使い捨てメールを、大量登録、トライアルの繰り返し利用、セキュリティ対策の回避に使わないでください。

あわせて、認証コードの有効期間、再送までの待機時間、最新のメールだけを有効とするか、認証成功後に同じコードを再利用できるかなど、想定するルールを整理します。これらはプロダクトの要件に基づくもので、テスターが推測するものではありません。使い捨てメールで認証コードを受信できても、登録システムのセキュリティルールが定まるわけではありません。

サービスが使い捨てメールを明確に拒否している場合は、「ドメインが受け入れられない」と記録し、何度もアドレスを変えて回避しようとせず、指定されたテスト用メールアドレスを使ってください。ソフトウェアのトライアルとゲームアカウントではリスクが異なります。まずは登録シーン別ガイドをご覧ください。

2. 4つの確認ポイント：各ステップを個別に判定する

登録フローのテストを4項目に分け、それぞれを「合格」「失敗」「要確認」で記録します。前のステップが合格でも、次のステップまで自動的に合格になるわけではありません。後の認証に失敗しても、それ以前に確認したメール受信の事実が無効になるわけではありません。

1. リクエスト送信済み：クリック操作、ページのフィードバック、画面上で確認できる応答を記録します。ボタンが「送信済み」に変わっても、それはアプリからの応答にすぎず、メールが送信システムを出た証拠にはなりません。
2. メール受信済み：実際に届いたメールの一覧からテストメールを見つけ、宛先、件名、テスト番号を確認します。前回のメールを今回のものと取り違えないようにしてください。
3. 内容を読める：送信者、用途、認証コード、有効期間の説明を確認し、デスクトップと狭い画面のどちらでも読めること、コピー結果が想定どおりであることを確かめます。
4. 認証成功：元のフローに戻ってコードを送信し、想定どおりのアカウント状態に進むことを確認します。ルールに従って、有効期限切れ、再利用、再送時の挙動もテストしてください。

操作を始める前に、4つの結果欄を用意しておくのがおすすめです。メールは届いたのにページでエラーが出た場合も、3番目と4番目のどちらで問題が起きたかを切り分けられ、全体を「メール受信失敗」とまとめずに済みます。

3. テスト前にアドレスの有効期間を確保する

FwdNestの新しい使い捨てアドレスは、初期状態で3時間有効です。延長するたびに3時間追加されます。ホームページに表示されるカウントダウンを確認してください。認証コードの有効期間は送信元アプリが決めるため、受信アドレスの残り時間とは別です。アドレスの有効期間があと2時間あっても、5分前に届いたコードがまだ使えるとは限りません。

テストを始める前に、操作、待機、再テスト、証拠の整理に必要な時間を見積もります。延長する場合は期限が切れる前に操作し、カウントダウンが更新されたことを確認してください。新しいアドレスに切り替えると古いアドレスは無効になり、以前のメールにもアクセスできなくなります。メールを待っている間に、むやみに切り替えないでください。

ブラウザーのアクセス情報も重要です。サイトデータを消去したり、別の端末に切り替えたりしても、元の受信トレイを再び開けるとは限りません。メールアドレスを復旧用の認証情報と考えたり、アクセス用トークンをチケットに貼り付けたりしないでください。長時間の作業には、有効期間の計画ページを使って、必要な時間を見積もれます。

4. 最小限のテスト項目表：まず条件の違いを確認し、必要に応じて項目を増やす

最小限のテスト項目表とは、あらゆる組み合わせをすべて試すことではなく、結果に影響する条件を網羅するものです。まず正常系を1つ実行し、その後は変数を1つずつ変えてテストします。環境、バージョン、ブラウザーを追跡できる状態にしておけば、どの変更が結果に影響したのかを特定できます。

別の端末でのテストでは、使い捨てメールボックスが自動で同期されると想定しないでください。安全でサポートされた方法で元の受信箱にアクセスできない場合は、チームが承認したテスト用メールアドレスを使い、受信経路が変わったことを記録します。認証情報を公開共有して、無理にテストを成立させないでください。

再送テストでは、特に送信頻度を管理してください。連続クリックするとメールの順序が分かりにくくなり、レート制限がかかることもあります。各テストに個別の番号を付け、「送信した順序」と「受信を確認した順序」を分けて記録してください。

5. 実際の認証コードを保存せず、時刻と結果を記録する

適切なテスト記録は、別の担当者があなたの認証コードを知らなくても再現できるものです。テスト番号、環境のバージョン、ブラウザー、タイムゾーン付きの時刻、期待値、実際の結果を記録します。アドレスは社内用の識別名か一部を伏せた表記にし、認証コードはすべて「マスク済み」と記載してください。

以下は架空の記録例であり、実際のテスト結果ではありません。時刻はページ上で確認した出来事を示すだけで、SMTPの受け付けにかかった時間の計算には使えません。チームで正確な性能テストを行う場合は、時刻の基準、ログへのアクセス権、集計方法を別途定めてください。

テスト番号：REG-026-B
環境バージョン：staging / build-026
ブラウザー：Firefox · Windows
時刻の基準：テスト端末の現地時刻、UTC+08:00
アドレスの識別名：TEMP-B（完全なアドレスは共有チケットに記載しない）

10:00:00  最初の送信リクエストを送信
10:00:01  ページに送信済みと表示
10:00:08  対応する実際のメールを一覧で初めて確認
10:00:12  狭い画面で読めることを確認。コピー結果に余分な空白なし
10:00:20  認証コード［マスク済み］を送信
10:00:21  想定されたアカウントページに移動

リクエスト：合格｜受信：確認済み｜閲覧：合格｜認証：合格
未完了：古いコード、期限切れコード、再利用のテストは別途記録
証拠：匿名化したスクリーンショット 026-B-01。トークンと認証コードは含まない

スクリーンショットは多ければよいわけではありません。アドレスバーにある機密性の高いパラメーターを切り取り、認証コード、アカウント識別情報、実際のメール内容をマスクしてください。共有前にファイル名、添付ファイル、ブラウザーのサイドバーも確認し、本文を隠した後に別の場所から情報が漏れていないか確かめましょう。

6. メールが届いても認証に失敗する場合は、表示と業務処理を分けて確認する

表示の問題：ユーザーが情報を正しく受け取れるか

数字が途中で切れていないか、ダークモードとライトモードの両方で見えるか、コピー時に改行や空白が入らないかを確認します。認証コードの表示に画像を使っているメールでは、画像を読み込めない場合にテキストで代替表示されるかも確認してください。テキスト版は読めるのにHTML版が読めない場合は、認証サービスをすぐに変更せず、まずテンプレートと表示互換性を調べましょう。

業務処理の問題：そのコードは現在の操作に対応しているか

内容が読め、入力にも誤りがない場合は、最新のリクエストに対応するコードか、有効期限が切れていないか、現在のメールアドレスとセッションに紐付いているかを確認します。認証処理が成功しても正しいアカウントに進めない場合も、フローの失敗です。テストを合格させるために、クライアント側でエラーを無視したり、認証コードの検証を緩めたりしないでください。

不具合を報告する際は、「メール受信を確認。コピーは正常。送信すると期限切れのメッセージが表示される」のように、失敗した箇所を明記してください。「認証コードがおかしい」だけの報告より、対応につながりやすくなります。バックエンドの調査が必要な場合は、権限のある担当者が照会できる機密情報を含まないテスト番号を伝え、実際の認証コードはチケットに記載しないでください。

7. メールが見えなくても、送信されていないとは限らない

ホームページは7秒ごとに受信トレイを確認します。これはページがメールを確認する間隔であり、実際の配信にかかる時間ではありません。ある確認時点で初めてメールを見つけた場合は、「初回確認時に受信」と記録できますが、その1秒前に届いたと断定することはできません。まして、送信サーバーがいつSMTPで受け付けたかを逆算することもできません。

メールが見つからない原因には、アドレスの入力間違い、一時アドレスの有効期限切れ、リクエストの未完了、送信待ち、送信元の制限、配信エラーなどが考えられます。通常、ブラウザー上の空の一覧だけでは原因を特定できません。まずアドレスと有効期間を確認し、送信ルールに従って待ってから、手動で1回更新して結果を記録してください。

自社システムの場合は、権限のある担当者にテスト番号を伝えて、タスクと配信ログを確認してもらえます。フロントエンドの記録とサーバー側の証拠は、別々の欄に保存してください。第三者のサービスでログを確認できない場合は、「メールを確認できず、原因は未確認」と記録し、「相手が送信していない」と断定しないでください。詳しい手順はメール受信のトラブルシューティングをご覧ください。

8. SteamとYouTubeのデモは、配信の証拠ではありません

FwdNestの受信トレイが空のときは、Steamの認証コードとYouTubeのコメント返信通知を表示します。どちらもデモであることを示す表示と免責事項が付いています。受信一覧やメール本文、認証コードの見方を説明するためのもので、外部サービスから実際に届いたメールではなく、このアドレスで実際にメールを受信できることの証明にもなりません。

デモに含まれるSteamのコードR7K2M、アカウントnestpilot_42、YouTubeの通知番号YT-4418-2093は、固定のサンプルです。デモのクリック、コピー、削除で確認できるのはデモ画面の動作だけです。これらの情報を実際のサービスに入力したり、スクリーンショットを「Steamの配信テスト合格」として扱ったりしないでください。

有効な証拠は、今回許可を得て実施したテストで送信された実際のメールです。テスト番号、宛先、操作時刻と照合できる必要があります。デモは表示を事前に確認するのに役立ちますが、実際のメールは別途確認してください。

9. テストから本番運用へ：受信アドレスを選び直す

使い捨てアドレスは、短期間の確認やテストデータの分離には適していますが、長期的なアカウント復旧には向きません。本番運用を始める前に、削除するテストアカウントと維持するアカウントを整理します。維持するアカウントは、チームのポリシーに沿って継続的にアクセスできるメールアドレスに移行し、新しいアドレスが有効になったことを確認してください。

サービスごとに受信元を分けたい場合は、長期転送コンソールでエイリアスを作成し、メールを普段使っている受信トレイに転送できます。ただし、エイリアスは転送サービス、受信側のメールボックス、各サービスの受け入れ状況に依存します。独立したバックアップや配信の保証にはなりません。

支払い、運用管理権限、重要な資産に関わるアカウントには、組織が承認した実際のメールアドレスと、十分な復旧手段を優先してください。長期転送の過去30日分のアーカイブも、永久保存ではありません。アドレスの選び方は、使い捨てメールとメールエイリアスの比較も参考にしてください。テストの手軽さだけで本番用の基準を決めないようにしましょう。

10. 最後に：テストを終え、古いアドレスも使い終える

テスト終了後は、確定した結果と未確認事項を分けて引き継ぎます。正常系が合格したからといって、未実施の期限切れ、古いコード、別端末でのテストまで成功扱いにしないでください。根拠のない項目は、理由と担当者を明記するほうが、根拠のない緑のチェックマークより役に立ちます。

• 不要になったテストアカウントを削除し、テストの許可と一時的なアクセス権を取り消す。
• アカウントを維持する場合は、まず登録アドレスを変更し、ログイン、通知、アカウント復旧の各手段を確認する。
• 匿名化したスクリーンショットを整理し、チームの保管ルールに従って元データと一時コピーを削除する。
• 未受信のメールを確認してから古いアドレスを使わなくする。アドレスの有効期限切れを、アカウントとの紐付け解除とみなさない。
• 環境のバージョン、テスト結果、未解決の問題を記録し、次回の回帰テストに備える。

テストで長期エイリアスを使った場合は、無効にする前にもう一度メールエイリアスの解約チェックリストを確認してください。本当にテストが完了したと言えるのは、認証コードが一度届いたときではありません。各ステップに根拠があり、テスト後に管理できない復旧手段を残していないことが大切です。