Prepare
Define the environment, language, device, and expected template.
QA MAIL RUNBOOK
Turn registration email testing into a repeatable checklist
Disposable addresses help isolate test data, but quality comes from clear prerequisites, timestamps, assertions, and cleanup—not from endlessly generating random accounts.
Trigger
Perform one send action at a time and record the timestamp.
Verify
Check the envelope, body, links, code, and responsive layout.
Clean up
Retire old addresses to keep test results from crossing over.
Execution checklist
Every test run should cover at least four layers
Record send time, arrival time, and click results in the defect report. A screenshot of the email’s appearance alone is not enough to pinpoint queue, template, or session issues.
Envelope fieldsThe From name, Reply-To, subject, recipient address, and language match the current use case.
Delivery behaviorEach send produces only the expected number of messages, latency is recorded, and resends follow the cooldown.
Message contentBoth plain text and HTML include a readable fallback, images are not too wide, and long links wrap.
Verification actionsThe code length, expiration, latest-code policy, and confirmation-link session binding are correct.
Narrow-screen readingAt a 390px viewport, the subject, sender, code, and body are fully readable without horizontal scrolling.
Failure pathsExpired codes, repeated use, incorrect email addresses, and rate limits show understandable messages.
Test matrix
Give every variable its own test case
| Variable | Minimum coverage | Record | Pass criteria |
|---|---|---|---|
| Language | Every language supported by the product | Requested lang and actual template | Subject, From, and body match |
| Client width | 390 / 760 / desktop | Overflow and tap targets | Body is fully usable |
| Verification-code status | Correct, incorrect, expired, and old code | Response and user message | No internal errors exposed |
| Send frequency | First send, during cooldown, after cooldown | Request count and countdown | No duplicate flooding |
When to use a disposable email for testing
Registration confirmation, product trials, verification-code delivery, and template compatibility are all well suited to isolated addresses. Use a fresh address for each case so historical messages do not affect the result.
Testing must be authorized by the system owner and comply with rate limits. Use a clear test prefix or test-data label to make backend cleanup easier.
Not suitable for load testing
A public disposable inbox is not load-testing infrastructure for bulk delivery, spam scoring, or bypassing registration limits. High-frequency automation distorts delivery data and can affect other users.
Run capacity and security tests in an isolated environment with a dedicated domain and controlled email sandbox, while retaining server logs and reproducible scripts.
Pre-release review
Do not miss the edge cases users actually encounter
Why test the latest-code policy?
Users may resend repeatedly and open an old message. The interface should clearly show that old codes are invalid and make the latest message easy to identify.
Is testing the HTML body alone enough?
No. Plain-text fallback, image-free mode, and wrapping for long links all affect reachability and accessibility.
How can test emails be kept from crossing over?
Use one address per test case and record the address and trigger time. Change addresses before starting the next case and close the old context.
What should I record when delivery is delayed?
Record the trigger time, the sender system’s queue time, arrival time, subject, and environment. Do not resend repeatedly while waiting.
Create a clean address for the next test case
Record the current result first, then change addresses to start a new testing context.