テストは成功したのに、検証メールを受信した証拠が残っていません。
最短の対処は、Playwright Test Agentsの生成コードを未確認のまま採用せず、メールの対応関係、認証の実効性、アカウント状態をそれぞれ確かめることです。テスト環境での成功は、その環境の外部宛てメールが本番でも届く証明にはなりません。
対象は、自社アプリの登録やメール認証テストをPlaywright Test Agentsで作成している開発者です。
メールフローの回帰テストを担当するQAエンジニアは、収件と状態変化の証拠を点検できます。
AIが生成したテストコードをレビューする技術責任者にも、マージやリリースの判断材料になります。
Playwright Test Agentsのメール認証テストで偽陽性を防ぐ
Playwright公式ドキュメントでは、Test Agentsをテスト計画を作るPlanner、Playwright Testファイルを生成するGenerator、失敗テストを修復するHealerとして説明しています。役割はテスト作成や修正であり、代理の実行が成功しただけでは、実際のメール受信まで確認したことになりません。Test Agentsの公式説明を確認し、生成テストに受信メールを読む処理と、そのメールに基づく検証が含まれているかをレビューしてください。
最初に見るべきなのは、合格条件がどこに置かれているかです。画面に「確認メールを送信しました」と表示されたことや、送信要求が成功したことだけを検証しているなら、メールが受信先に到達した証拠にはなりません。受信したメール本文など、管理下のテスト受信環境から確認できる情報を、対応する実行記録と一緒に残します。
| 確認対象 | その確認だけで分かること | 受け入れ評価 |
|---|---|---|
| 画面の完了メッセージ | 画面上で送信処理を案内したこと | 受信の証拠としては不足 |
| 送信要求の成功 | アプリから送信処理が呼ばれたこと | 配信先での受信は未確認 |
| 管理下の受信箱にあるメール | テスト環境でメールを読み取れたこと | 実際のメールを使う確認として有効 |
| 認証後のアカウント状態 | アプリが認証結果を反映したこと | メール確認と組み合わせて合格判定 |
この評価は、検証の証拠として何が確認できるかを整理したものです。送信処理の種類や特定の受信方法を推奨するものではありません。Playwrightのアサーションに関する公式資料では、条件を満たすまで再試行するアサーションが説明されていますが、再試行が成功しても、メールと今回の実行が対応しているかは別に確認する必要があります。
今回の実行で送ったメールだとどう確かめる？
並列実行やリトライがあると、受信箱に残っていた古いメールや、別のテストが作ったメールを拾うおそれがあります。受信メールが認証コードを含んでいても、それが今回作成したアカウント宛てでなければ、テストの成功を裏付ける証拠にはなりません。
次の手順で、メールと実行の対応を確認します。
- 実行を識別する情報を用意します。 テスト実行ごとに識別できるアドレス、アカウント、または自社アプリが扱う追跡情報を使います。運用上それらを分けられない場合は、実行が並行しない条件やメールを選ぶ条件を明示します。
- 受信対象を照合します。 メールの宛先が、今回登録したアカウントのアドレスと一致していることを確かめます。
- 本文の内容を確認します。 自社アプリが生成した認証コードやリンクが、今回のメールに含まれていることを読み取ります。
- 実行記録と結び付けます。 使用したテストアカウント、受信メールの識別情報、認証結果が一緒に追跡できるようにします。
- 取り違えた場合の失敗条件を決めます。 宛先や実行識別情報が一致しないメールは使わず、該当するメールを特定できなければテストを成功扱いにしません。
Playwrightのリトライに関する公式資料では、再実行を含むテスト結果の扱いが説明されています。リトライを使う場合も、前回の実行で受信したメールが残っていて今回の処理と混ざらないかを確認してください。受信アドレスとメールを実行ごとに管理する考え方は、QA向けのメール作業環境を検討するときにも役立ちます。
認証コードを読んだだけで終わらせない
本文からコードやリンクを取得できたことは、メール内の情報を読み取れた証拠です。しかし、その情報が有効で、アプリがアカウント認証に反映したかまでは証明しません。メール認証のE2Eテストでは、メールの読取をアプリ内での認証操作につなげ、その後のアカウント状態まで断言する必要があります。
レビュー時には、生成コードが次の流れを実際に通っているかを確認します。
- 自社アプリでテスト用アカウントを作成します。
- そのアカウントに届いたメールを特定し、コードまたはリンクを読み取ります。
- 読み取った値を自社アプリの認証画面で使用します。
- 認証後に、未認証状態から期待する状態へ変化したことを確かめます。
- 認証に失敗した場合は、成功時とは異なる結果になることも確認候補にします。
無効なコード、期限切れのコード、使用済みリンクなどをどう扱うかは、自社製品の仕様に合わせて決めてください。すべての製品に同じ挙動を期待するのではなく、仕様に定めた拒否やエラー表示が確認できるかを評価します。アカウント状態の確認では、画面の文言だけで済ませず、テスト対象のアプリで認証済みとして扱われる条件に沿った断言を置くことが重要です。
Healerの修正後は、断言が残っているかを採点する
失敗後にHealerがコードを直し、再実行で成功しても、そのまま修正を受け入れるのは危険です。修正によって受信メールの確認、コードやリンクの検証、最終状態の断言が削られていれば、テストは通りやすくなった代わりに、確かめる内容が弱くなっている可能性があります。
修正前後を比べ、失敗の原因に対応した変更か、失敗条件を無視する変更かを見分けます。たとえばメールを読む処理が画面の完了表示だけに置き換わっていないか、認証操作の後にアカウント状態を確かめる断言が残っているかを確認します。どの条件が直ったため成功したのかを説明できない場合は、レビューを完了せず、修正を保留します。
PlaywrightのTrace Viewer公式資料を使うと、テスト実行を追跡して失敗箇所や操作の流れを調べられます。トレースは原因調査の材料ですが、テストの期待値が妥当かどうかの代わりにはなりません。変更差分と実行証拠の両方を見て判断してください。
注意：Playwrightのアサーションに設定された既定のタイムアウトは5秒です。公式のアサーション資料に記載されたこの値は、アサーションが条件を待つ設定であり、メール配信の保証時間や本番の到達基準ではありません。
テスト通過で本番の送達まで証明できる？
証明できる範囲は、テスト環境で実際に検証したところまでです。管理下の受信先でメールを読み、認証操作とアカウント状態の変化を確認できれば、自社アプリのメール認証フローに関する証拠になります。一方、それだけでは本番の送信ドメイン認証、外部の各受信サービスでの処理、迷惑メール判定や外部宛ての到達状況は分かりません。
リリース判断では、目的を分けて確認します。アプリ内の認証フローを確かめる試験と、公開環境から実際の受信先へ送る試験は、異なる問いに答えるものです。対象とするリリース条件に本番メールの確認が含まれるなら、許可された環境と受信先を使い、別途その範囲を検証してください。テスト受信の成功を、すべての受信者に届くという結論へ広げないことが大切です。
実行ごとに合否の証拠を残す
受け入れ記録には、テスト実行を識別する情報、使用したアカウントまたは宛先、今回の実行に対応するメールを特定した根拠、認証コードまたはリンクを使った結果、最終的なアカウント状態を含めます。失敗時には、どの確認段階で止まったのかも残してください。これにより「テストが緑だった」という結果だけでなく、何を確かめて合格としたかを後から追えます。
メールを受信できなかった場合、登録画面の成功表示だけで代用せず、受信の証拠がない状態として扱います。逆にメールを読めても、認証後のアカウント状態が期待と一致しなければ、フロー全体の合格にはできません。
実メールを読む必要がある自社製品のテストでは、管理下のテスト受信先を用意する方法の一つとして、一時メールアドレスも検討できます。Forwardtmpを利用する場合は、実際の受信機能とメールの保持条件を事前に確認し、テスト目的に合うと判断できた範囲で使ってください。受信できたことはアプリの検証材料になりますが、本番の外部送達を保証するものではありません。利用条件はForwardtmpの案内で確認できます。