1. テスト準備
本番環境ではなく合成ユーザーを使い、受信アドレスがまだ有効か確認します。
ビルド番号、テンプレートのバージョン、言語、トリガー時刻、期待結果を記録します。
今回のテストケースに一意のイベント番号を設定し、ログから受信トレイまで追跡できるようにします。
開発・QAチェックリスト
送信前と到着後に、テストメールを一つずつ確認
メールが「届く」だけでは十分ではありません。このチェックリストで、業務トリガー、受信者情報、コンテンツ構成、行動導線、タイミング、失敗経路、プライバシーの境界を同時に確認し、再現可能なリリース判断につなげましょう。
対象範囲
6つのチェックで完全な回帰テストを実施
カードは単なる装飾ではありません。テスト順に左から右へ進め、ブロッカー項目の失敗を「もう一度送る」だけで通過させないでください。
2. トリガーと配信
業務アクションによって、正しい宛先へのメールが1通だけ生成され、重複や誤送信がないことを確認します。
キューが正常に処理され、送信サービスのイベントが同じメッセージIDに対応していることを確認します。
到着までの時間が想定範囲内で、遅延やバウンスの状態を理解できることを確認します。
3. 件名とプレビュー
差出人名とアドレスを識別でき、Reply-Toが想定した窓口を指していることを確認します。
件名が明確で変数も正しく、環境名、対象、プレースホルダーが漏れていないことを確認します。
プレビュー文が件名を補足し、見出しを繰り返したり、CSSや配信停止用の断片を露出させたりしないことを確認します。
4. 本文と行動導線
見出し、説明、主要ボタンの階層が明確で、ユーザーが次の操作を迷わず理解できることを確認します。
ボタンの文言が具体的で、遷移先のドメインが正しく、トラッキングパラメータが遷移を妨げないことを確認します。
画像に代替テキストがあり、画像を無効にしても主要なタスクを理解できることを確認します。
5. 認証コードとセキュリティ
コードの桁数、有効期限、ページ上の案内が一致し、目立つ位置に表示されていても件名には含まれていないことを確認します。
再送時の新旧コードの関係がルールどおりで、期限切れコードが明確に無効になることを確認します。
ログやエラーメッセージに、完全な認証コード、トークン、復旧リンクを露出させないでください。
6. 互換性と仕上げ
デスクトップでも狭い画面でも横方向のはみ出しがなく、ライト・ダークモードのどちらでも文字が読みやすいことを確認します。
プレーンテキスト版でも同じ操作を説明し、長いリンクや単語が適切に折り返されることを確認します。
テストデータを計画どおり削除し、使い捨てアドレスを本番アカウントのプロフィールに残さないでください。
IDとトリガー条件を再現可能にする
テスト前に「誰が、どの状態で、何をしたのか」を明確にし、送信されるべき条件と送信されてはいけない条件を列挙します。成功経路だけをテストすると、通知設定の無効化、アカウント認証済み、重複イベントの排除など重要な分岐を見落とします。
受信アドレスは現在のテストツールバーからコピーし、手入力を避けます。アドレスを変更したらテストユーザーも更新してください。以前のメールは移行されないため、新旧アドレスを混在させると結果の信頼性が失われます。
認証コードとリセットリンクはセットでテストする
コードの長さ、文字種、有効期限、1回の使用後に無効になること、再送ルールを確認します。ページには10分と表示されているのにバックエンドでは5分で期限切れになるなら、文言の小さな問題ではなく業務上の欠陥です。
無効なコード、期限切れコード、連続入力、頻繁な再送に対するフィードバックも確認します。リンク認証では、プロトコル、ホスト名、環境、一度限りのトークン、遷移後の最終ページを確認し、ボタンをクリックできることだけで判断しないでください。
HTML・画像・プレーンテキストを個別に確認する
メール本文で、コンテナ幅、見出しの折り返し、ボタンの高さ、段落間隔、画像の拡大縮小を確認します。長い名前、長いプロジェクト名、フランス語やポルトガル語のボタンは中国語よりレイアウトを崩しやすいため、妥当な範囲で最も長いサンプルを使って回帰テストします。
画像を無効にしても、ブランドと主要なタスクを認識できるようにします。プレーンテキスト版には認証コード、有効期限、リンク、サポート情報を残してください。内容をすべて画像に詰め込んだり、非表示のプレビューテキストを本文の1行目に表示させたりしないでください。
リンク・添付ファイル・返信動作を見た目だけで判断しない
主要ボタン、補助リンク、ヘルプ導線、配信停止リンクを1つずつ開き、対象ドメイン、パス、パラメータ、ログイン状態が正しいことを確認します。テスト環境のリンクが本番の書き込み操作を誤って指したり、本番テンプレートにテストドメインが含まれたりしないようにします。
添付ファイルのファイル名、種類、サイズ、権限を確認し、危険な種類はブロックまたは隔離されることを確認します。メールに返信する際は、Reply-Toが想定したサポート窓口に届くことを確認し、監視されていない送信元アドレスに返信されないようにします。
言語・タイムゾーン・アクセシビリティを統一する
件名、プレビュー、本文、ボタン、エラー表示は同じ言語にし、日付、金額、タイムゾーンはユーザーの地域形式で表示します。翻訳がない場合は管理されたフォールバックを使い、1通のメール内で言語を無作為に混在させないでください。
見出しの階層を連続させ、リンク文言で目的を説明し、画像には適切な代替テキストを設定します。状態を色だけで伝えないでください。白背景の薄い文字や、色付き背景の濃い文字でも十分なコントラストを確保します。
失敗・遅延・重複もプロダクト体験の一部
キューの遅延、サービスプロバイダーによる一時拒否、恒久的なバウンスを再現し、ルールどおりに再試行しつつ重複通知を防げるか確認します。ユーザーインターフェースには操作可能な状態を示し、すべての失敗を「ネットワークエラー」とだけ表示しないでください。
テストメールが届かない場合は、アプリ、キュー、送信プラットフォーム、DNS、受信側の証跡を順にたどって診断します。最初の失敗の証拠を残してから修正を検証し、再送が一度成功したからといって元の手がかりを削除しないでください。
リリース基準をリスク別に設定する
| レベル | 例 | リリース基準 | 失敗時の対応 |
|---|---|---|---|
| ブロッカー | メールが生成されない、宛先が誤っている、認証コードが使えない、主要リンクが誤っている | すべて合格すること | リリースを停止し、根本原因を修正する |
| 高 | 重複送信、有効期限の不一致、モバイルで本文が切れる | 修正するか、責任者が書面で受け入れること | 明確な期限と回帰テストケースを設定する |
| 中 | プレビューの重複、補助リンクのラベルが不明確、長文の折り返しが不適切 | 対象ユーザーと頻度を評価する | 直近のイテレーションに入れ、証跡を残す |
| 低 | タスクに影響しない軽微な表示上のずれ | 主要フローをブロックしない | テンプレートとクライアントの対象範囲を記録する |
チェック結果を追跡可能な証跡にする
テストケース番号、環境、テンプレートのバージョン、言語、受信アドレスのプレフィックス、トリガー時刻と到着時刻、メッセージID、結果、バグへのリンクを記録します。スクリーンショットには件名と本文の重要部分を含めますが、トークンや実在する個人データはマスキングしてください。
修正後は同じ条件で回帰テストを行い、最も近い失敗経路も追加で確認します。配信トラブルの特定にサポートが必要な場合は、メール配信診断ガイドを利用するか、 support@msgtmp.comまでご連絡ください。