Delivery facts
Check the task response, queue status, recipient address, actual arrival time, and duplicate sends. If nothing arrives, start with evidence from the sending side.
Email test cases
Cover delivery, content, and behavior with one matrix
Cross-reference email types with validation dimensions instead of testing whatever comes to mind. The matrix works for verification codes, signup confirmations, notifications, and marketing templates.
| Email type | Delivery | Content | Interaction | Failure path |
|---|---|---|---|---|
| Login verification code | Exactly one email per trigger | Six-digit code and expiration match | Verification succeeds after copying | Old code expires; request rate is controlled |
| Signup confirmation | Correct destination and environment | Correct product name and account details | Confirmation link works only once | Expired link gives clear feedback |
| Security alert | Arrives promptly after the event | Time, device, and location can be verified | Security entry points to the correct domain | Clear steps exist for unauthorized activity |
| Product notification | Subscription status determines whether it sends | Subject matches the actual version | Deep link opens the target page | No further sends after unsubscribing |
Four dimensions
Start broad, then investigate the risks
A matrix is not about mechanically running every combination. It makes sure critical risks are not hidden behind polished screenshots.
Content facts
The subject, sender, preheader, body, amounts, dates, and expiration must match the product interface and event data.
User behavior
After copying a code, opening a confirmation link, replying, or unsubscribing, users should get a clear result they can recover from.
Failure boundaries
Cover expiration, repeated clicks, incorrect accounts, rate limiting, oversized attachments, and already-used links—not just successful flows.
Client width
Check both desktop and narrow reading areas to ensure long subjects, buttons, tables, and URLs do not break the message layout.
Data isolation
Use a newly marked address for every round to keep old messages, caches, or shared test inboxes from distorting the results.
What to retain for failed test cases
- Environment, template version, and send task ID
- Full destination address and trigger time
- Expected delivery window and actual observation time
- Inbox screenshot, original subject, and link destination
How to keep the matrix manageable
Prioritize by impact and likelihood. For login, security, and payment emails, cover success, expiration, and duplicate actions first, then expand across clients.
- Run high-risk features in every release
- Sample low-risk visual regression tests by template version
- Mark known third-party delays with a separate waiting window
Execution order
Keep one causal chain per test round
The address, template, trigger, time, and result must connect. Conclusions that cannot be reproduced should not directly determine release decisions.
PrepareCreate an isolated address and note the template version, environment, and expected delivery window.
TriggerPerform the target action once, save the request or task ID, and avoid repeated clicks that create duplicate emails.
ObserveRefresh the test inbox, record the actual arrival time, then open the full message and its links.
Close outWrite the behavior and evidence back into the test case. After fixing it, retest with a new ID and a new address.