メールHTMLは多くの制約がある実行環境です。クライアントはスタイルを削除し、画像をプロキシ経由にし、リンクを書き換えることがあります。ダークモードでは色が再計算される場合もあります。一方、テンプレートはもはや静的なページだけではなく、通常はコンポーネント、ローカライズ文言、動的データから生成されます。信頼できる回帰テストでは、データ契約、構造と表示、操作の導線、実際の配信を同時に確認する必要があります。
このガイドは、ウェルカムメール、請求通知、チーム招待、パスワードリセット、プロダクト通知に適しています。認証コードメールでは、コードの照合と再送テストも追加で必要です。別記事の 認証コード完全テストケース も併せてご利用ください。
「完璧なスクリーンショット」ではなく比較可能な基準を作る
スクリーンショットは理解しやすい一方、メールで使われたデータやクリックできるリンクを示せず、見えないプレビュー文も発見できません。より良い基準には、テンプレートのバージョン、入力サンプル、生成後のHTMLとプレーンテキスト、実際の配信記録の4つを含めます。こうすれば差分が出たとき、テンプレート、データ、配信経路のどこが変わったのか分かります。
さまざまな内容の形をサンプルに含める
テンプレートごとに、短い件名、長い件名、空の任意項目、長い名前、多言語、複数のリスト項目を用意します。「山田太郎」と商品1行だけでは不十分です。実際のレイアウト問題は、長いドイツ語風の語句、スペースのない日本語テキスト、桁数の多い金額、アバターの欠落などで発生します。現段階で中国語を使う場合でも、コンポーネントにはこうした形を想定した余地を残しておきましょう。
- 最短と最長の件名で、受信トレイ一覧の省略後も内容を判別できるか確認する。
- 名前、プロジェクト名、注文番号が上限に近い組み合わせ。
- 項目数が0件、1件、複数件のリストで、条件付きブロックに空白が残らないか確認する。
- 画像なし、読み込みの遅い画像、異常に幅の広い画像で、コンテナの境界を検証する。
まずコンテンツの契約を確認し、ピクセルはその後に見る
レンダリング前に、生成結果にテンプレートの残骸がないかスキャンします。たとえば {{name}}、${url}、空の括弧、開発用ドメインなどです。件名、プレビュー文、本文の見出し、主要ボタンは同じ操作を説明する必要があります。件名には「請求書を作成しました」とあるのに、開くとマーケティング更新しか表示される、といった状態は避けてください。
すべての動的な値をエスケープし、適切にフォーマットします。ユーザー入力をHTMLにしてはいけません。金額には正しい通貨と小数点ルールを適用し、時刻にはタイムゾーンを明示するかユーザーのタイムゾーンを使用します。番号が表計算ソフトによって指数表記に変換されないようにします。データがない場合は該当する文を省略し、「undefined」をユーザーに送信してはいけません。
意味を確認してから、見た目を確認する：ボタンのラベル、リンク先URL、有効期限が間違っていれば、すべてのクライアントでピクセル単位に一致していても公開できません。
プレビュー文と非表示コンテンツを確認する
受信トレイ一覧では、件名とpreheaderが最初に表示されることがよくあります。プレビュー文は件名を補足するものであり、見出しを繰り返したり、「ブラウザで表示」、CSSの断片、画像の代替テキストを拾ったりしてはいけません。プレビュー制御用の非表示文字が、一部のクライアントで大きな空白を作らないようにします。
すべてを網羅しようとせず、リスクマトリクスでクライアントを選ぶ
実際の製品利用データから主要なデスクトップ、Web、モバイルのクライアントを選び、既知の差異が大きいエンジンを追加します。コミットごとにコアマトリクスを実行し、リリース候補では拡張マトリクスを実行します。これにより時間を抑えつつ、「20種類のクライアントをテストした」ことで利用率の高い3種類を見落とす事態も防げます。
表示確認はタスクの完了を中心に行う
- コンテンツ幅はデスクトップで600～700ピクセルに収まり、狭い画面で横スクロールが発生しない。
- 見出し、本文、主要ボタンの階層が明確で、ファーストビューだけでメールの目的を理解できる。
- ボタンのクリック領域が十分にあり、文字が長くなったときは折り返すが切り取られない。
- メールレイアウトにテーブルを使う場合も意味的な代替を用意し、読み上げ順が乱れない。
- ダークモードでも本文、リンク、ブランド画像、ボタンに十分なコントラストがある。
「クライアントによる拡大を許可する」ことをレスポンシブデザインと見なしてはいけません。大きな画像、固定幅のテーブル、改行できない長い文字列は、メール全体をビューポートからはみ出させます。注文番号やトラッキングリンクには適切な改行方法を使いますが、認証コードや短い金額は通常、途中で分割しないようにします。
リンク、パラメータ、有効期限の動作を1つずつ検証する
生成されたHTMLからすべてのリンクを取得し、主要操作、補助操作、ナビゲーション、配信停止、法的リンクに分類します。各リンクはHTTPSの正式またはテスト用ドメインを使い、localhost、内部ホスト名、テンプレートのプレースホルダーを残してはいけません。トラッキングパラメータは使用できますが、業務用パラメータを壊したり、長期間拡散されるURLに機密情報を書き込んだりしてはいけません。
主要ボタンを手動でクリックし、リダイレクト後に想定したページへ移動し、必要なコンテキストが保持されることを確認します。ログインリンクとリセットリンクは期限切れ後に失敗し、正常に使用した後は再利用できないようにします。通常のコンテンツリンクは、短期署名によって早く無効にならないようにします。
見た目のボタンと実際のリンクを区別する
一部のクライアントは複雑なCSSを削除しますが、実際の <a> 要素はクリックできます。スクリプト、フォーム、画像の一部にだけクリック領域を設定して操作を実装するのは避けてください。ボタンの文言だけで遷移先を説明し、「ここをクリック」とだけ書かないようにします。スクリーンリーダーの利用者が文脈を離れても意味を理解できることが必要です。
画像をオフにし、プレーンテキストでもう一度読む
画像はデフォルトでブロックされたり、プロキシ経由で遅延したりすることがあります。画像をオフにしてもロゴの欠落で識別性が損なわれず、主要操作がポスター画像の中だけに存在しないようにします。代替テキストはファイル名の繰り返しではなく内容を説明してください。装飾画像には空の代替テキストを使い、スクリーンリーダーが重要な内容として読み上げないようにします。
プレーンテキスト版はHTMLタグを乱暴に削除しただけのものではありません。明確な段落、完全なURL、同じ動的データ、一貫した安全上の注意が必要です。HTMLでリンクの有効期限を30分としているなら、プレーンテキストでも同じでなければなりません。複数カラムの内容は、線形テキストで自然な順序に並べます。
アクセシビリティと認知負荷をテストする
見出しの階層、リンク文言、色のコントラスト、読みやすい文字サイズを確認します。「成功」や「警告」を色だけで表現せず、同じ重要度の5つの操作を5つの主要ボタンとして並べないようにします。メールの目的は通常1つだけです。補足情報は視覚的な優先度を下げます。
長期的に続けるには回帰テストを3層に分ける
第1層はコードのコミット時に実行します。テンプレートがコンパイルできること、変数が揃っていること、リンクのドメインが許可リスト内であること、HTMLサイズが上限を超えないこと、プレーンテキストが存在することを検証します。第2層はステージング環境から実際に送信します。 隔離テスト受信トレイ で受信し、件名、送信者、メッセージID、到着時刻を記録して本文を開きます。第3層はリリース候補で手動のマトリクス確認を行い、主要クライアント、狭い画面、ダークモード、画像なし、スクリーンリーダーの読み上げ順を対象にします。
失敗したときはスクリーンショットだけでなく、生成時の入力と出力を保存します。送信サービスにacceptedと表示されても、受信トレイに届いたとは限りません。テスト受信トレイが空の場合は、アプリケーションログ、キュー、サービスプロバイダーのイベントと照合します。 メール配信診断 の証跡の順序に沿って原因を特定できます。
変更内容に応じて異なる基準を設ける
スペルだけの変更なら、すべてのクライアントを再実行する必要はありません。しかし、レイアウトコンポーネント、インライン化ツール、リンク生成器、国際化フレームワークを変更した場合は、マトリクスを拡大すべきです。変更の種類をプルリクエストのテンプレートに記載し、実施者が必要な証跡のレベルを判断できるようにします。古い基準は定期的に整理し、バージョンと理由を残して、差異を見過ごさないようにします。
最後に、 テストメールチェックリスト を使って、件名、プレビュー、本文、リンク、タイミング、プライバシーの境界をつなげて確認します。回帰プロセスの価値はスクリーンショットを増やすことではなく、ユーザーが誤ったメッセージを受け取る前に、チームへ明確で再現可能なリリース停止シグナルを出すことにあります。