QAメールワークベンチ

ブラウザでテストメールの受信フローを一通り実行

「メールが届いた」を検証可能なチェックポイントに分解しましょう。トリガー、キュー、到達、一覧の概要、本文の表示、リンク、添付ファイルを確認します。使い捨てアドレスなら、テストごとにデータを分離できます。

今回のテストに必要な情報を先に決める

実行ごとに、再現に必要な最小限の情報を残します。「たまに届かない」だけで済ませないようにしましょう。

環境

送信元を明確にする

本番、ステージング、ローカルのどれか、使用したテンプレートのバージョンと言語を記録します。

識別

実行ごとに新しいアドレスを使う

現在の使い捨てメールアドレスをコピーし、古いメールや重複タスクが未読数、並び順、件数に影響しないようにします。

時刻

トリガーと到達時刻を記録する

送信を実行した時刻と一覧に表示された時刻を記録し、比較可能な遅延データを取得します。

関連付け

機密情報を含まないテスト番号を付ける

件名にビルド番号やケース番号を入れ、実在のユーザー情報や本番用キーは記載しません。

実行手順

8つのチェックポイントで「問題なさそう」を見逃さない

一覧と詳細は分けて検証します。実際のメールが届いたら、デモ行が一覧から消えることも確認します。

メールを一度だけ送信する

APIまたはプロダクト画面が成功を返したことを確認し、リクエストの関連IDを保存します。すぐに連続送信しないでください。

一覧に表示される時刻を確認する

自動更新を待ちます。必要なら手動更新を1回行い、目に見えるフィードバックがあることを確認します。トリガーから表示までの秒数を記録します。

送信者と返信先アドレスを確認する

表示名、アドレスのドメイン、Reply-Toが環境設定と一致し、開発用アドレスや誤ったブランド名が漏れていないことを確認します。

件名とプレビューを確認する

変数がそのまま表示されないこと、長い件名が一覧を崩さず省略されること、時刻がローカル形式で表示されることを確認します。

行全体を開いて詳細を読む

HTML本文は隔離されたフレーム内に表示し、テキスト本文はフォールバックとして表示します。モバイルの閲覧領域はビューポート全体に広がるようにします。

認証コードと主要ボタンを確認する

認証コードは読めてもログに記録されないこと、ボタンの文言が明確で、遷移先のドメインが環境と一致することを確認します。

添付ファイルとフォールバックを確認する

ファイル名、種類、サイズ、認証付きダウンロードをすべて確認します。HTMLがなくてもテキスト本文が表示される必要があります。

結果を保存してアドレスを替えて再テストする

成功、失敗、スクリーンショットを記録し、新しいアドレスでテストの再現性を確認します。キャッシュで問題を隠さないようにします。

推奨する最小テストマトリクス

ケース入力の変化主なアサーション
6桁の認証コード中国語・英語テンプレートコード値、有効期限、ブランドカラー、送信者
確認リンク長いユーザー名と長いURL折り返し、ボタンの遷移先、テキスト本文のフォールバック
通知メール件名なし、またはプレビューなしローカライズされたプレースホルダー、一覧レイアウト
HTMLマーケティングメール画像の無効化と狭い画面隔離表示、画像幅の制限、配信停止情報
添付ファイル付きメール中国語のファイル名と複数ファイル名前のエンコード、ダウンロード認証、失敗時のフィードバック
重複送信同じアドレスへの2回のトリガー並び順、未読状態、重複排除の方針

実行につながるバグ報告を書く方法

タイトルには環境、テンプレート、現象を明記します。例:「ステージングの中国語認証コードメールがモバイル閲覧画面で横にはみ出す」。本文にはトリガー時刻、到達時刻、アドレスのドメイン、ブラウザ、期待結果、実際の結果を添えます。

実際の認証コード、完全な受信アドレス、ユーザーのメール本文を公開バグ管理システムに貼り付けないでください。サンプルを共有する場合は、専用に生成したテストデータを使い、トークンをマスキングします。

継続的な転送テストに切り替えるタイミング

1回のビルド確認には使い捨てメールが適しています。数日間にわたる回帰テスト、配信状況、添付ファイルの再試行には、専用の転送IDが適しています。転送IDなら入口を長期的に維持しながら、QAメンバーの公開用個人アドレスを汚さずに済みます。

どのIDを使う場合も、使い捨てメールサービスを負荷テストの対象にしないでください。高頻度の自動リクエストはレート制限を招き、実際のユーザーにとって意味のある測定ができなくなります。