送信元を明確にする
本番、ステージング、ローカルのどれか、使用したテンプレートのバージョンと言語を記録します。
QAメールワークベンチ
「メールが届いた」を検証可能なチェックポイントに分解しましょう。トリガー、キュー、到達、一覧の概要、本文の表示、リンク、添付ファイルを確認します。使い捨てアドレスなら、テストごとにデータを分離できます。
実行ごとに、再現に必要な最小限の情報を残します。「たまに届かない」だけで済ませないようにしましょう。
本番、ステージング、ローカルのどれか、使用したテンプレートのバージョンと言語を記録します。
現在の使い捨てメールアドレスをコピーし、古いメールや重複タスクが未読数、並び順、件数に影響しないようにします。
送信を実行した時刻と一覧に表示された時刻を記録し、比較可能な遅延データを取得します。
件名にビルド番号やケース番号を入れ、実在のユーザー情報や本番用キーは記載しません。
実行手順
一覧と詳細は分けて検証します。実際のメールが届いたら、デモ行が一覧から消えることも確認します。
APIまたはプロダクト画面が成功を返したことを確認し、リクエストの関連IDを保存します。すぐに連続送信しないでください。
自動更新を待ちます。必要なら手動更新を1回行い、目に見えるフィードバックがあることを確認します。トリガーから表示までの秒数を記録します。
表示名、アドレスのドメイン、Reply-Toが環境設定と一致し、開発用アドレスや誤ったブランド名が漏れていないことを確認します。
変数がそのまま表示されないこと、長い件名が一覧を崩さず省略されること、時刻がローカル形式で表示されることを確認します。
HTML本文は隔離されたフレーム内に表示し、テキスト本文はフォールバックとして表示します。モバイルの閲覧領域はビューポート全体に広がるようにします。
認証コードは読めてもログに記録されないこと、ボタンの文言が明確で、遷移先のドメインが環境と一致することを確認します。
ファイル名、種類、サイズ、認証付きダウンロードをすべて確認します。HTMLがなくてもテキスト本文が表示される必要があります。
成功、失敗、スクリーンショットを記録し、新しいアドレスでテストの再現性を確認します。キャッシュで問題を隠さないようにします。
| ケース | 入力の変化 | 主なアサーション |
|---|---|---|
| 6桁の認証コード | 中国語・英語テンプレート | コード値、有効期限、ブランドカラー、送信者 |
| 確認リンク | 長いユーザー名と長いURL | 折り返し、ボタンの遷移先、テキスト本文のフォールバック |
| 通知メール | 件名なし、またはプレビューなし | ローカライズされたプレースホルダー、一覧レイアウト |
| HTMLマーケティングメール | 画像の無効化と狭い画面 | 隔離表示、画像幅の制限、配信停止情報 |
| 添付ファイル付きメール | 中国語のファイル名と複数ファイル | 名前のエンコード、ダウンロード認証、失敗時のフィードバック |
| 重複送信 | 同じアドレスへの2回のトリガー | 並び順、未読状態、重複排除の方針 |
タイトルには環境、テンプレート、現象を明記します。例:「ステージングの中国語認証コードメールがモバイル閲覧画面で横にはみ出す」。本文にはトリガー時刻、到達時刻、アドレスのドメイン、ブラウザ、期待結果、実際の結果を添えます。
実際の認証コード、完全な受信アドレス、ユーザーのメール本文を公開バグ管理システムに貼り付けないでください。サンプルを共有する場合は、専用に生成したテストデータを使い、トークンをマスキングします。
1回のビルド確認には使い捨てメールが適しています。数日間にわたる回帰テスト、配信状況、添付ファイルの再試行には、専用の転送IDが適しています。転送IDなら入口を長期的に維持しながら、QAメンバーの公開用個人アドレスを汚さずに済みます。
どのIDを使う場合も、使い捨てメールサービスを負荷テストの対象にしないでください。高頻度の自動リクエストはレート制限を招き、実際のユーザーにとって意味のある測定ができなくなります。