Identify the sending environment
Record whether it’s production, staging, or local, along with the template version and language used.
QA email workbench
Run a complete email delivery test in your browser
Break “the email arrived” into verifiable checkpoints: triggering, queuing, delivery, list preview, body rendering, links, and attachments. Temporary addresses keep each test’s data isolated.
Define this run’s test credentials first
Keep the minimum information needed to reproduce each run—avoid reporting only that delivery is intermittent.
Use a fresh address for every run
Copy the current temporary email address so old messages and repeat tasks don’t affect unread status, sorting, or counts.
Record trigger and delivery times
Note when sending was triggered and when the message appeared in the list to get comparable latency data.
Add a non-sensitive test ID
Add a build or case number to the subject—never include real user data or production secrets.
Execution order
Eight checkpoints keep “looks fine” from passing as a test
Validate the list and message details separately; once the real email arrives, the demo row should disappear from the list.
Trigger the email once—and only once
Confirm that the API or product page reports success, and save the request correlation ID. Don’t click Send repeatedly right away.
Watch when the message appears in the list
Wait for automatic refresh, then optionally refresh once manually and confirm visible feedback. Record the seconds from trigger to appearance.
Verify the sender and reply address
The display name, address domain, and Reply-To should match the environment settings. Development addresses or incorrect brands must not appear.
Verify the subject and preview
Variables should not appear as raw placeholders. Long subjects should be truncated rather than breaking the list, and times should use the local format.
Open the full row to read the details
Render the HTML body in an isolated frame, with plain text as a fallback. On mobile, the reading view should fill the viewport.
Check the verification code and primary buttons
The code should be readable but must not be logged. Button labels should be clear, and the target domain should match the environment.
Check attachments and fallback paths
Verify the filename, type, size, and authenticated download. When HTML is unavailable, plain text should still be visible.
Save the result, then retest with a new address
Record passes, failures, and screenshots. Use a fresh address to confirm repeatability and prevent caching from hiding problems.
Recommended minimum test matrix
| Case | Input variation | Key assertions |
|---|---|---|
| Six-digit verification code | Chinese and English templates | Code value, expiry, brand color, sender |
| Confirmation link | Long username and long URL | Wrapping, button target, plain-text fallback |
| Notification email | No subject or missing preview | Localized placeholders, list layout |
| HTML marketing email | Images disabled and narrow screens | Isolated rendering, image width constraints, unsubscribe details |
| Email with attachments | Chinese filenames and multiple files | Name encoding, download authentication, failure feedback |
| Duplicate sending | Two triggers to the same address | Sorting, unread status, deduplication strategy |
How to write an actionable bug report
Make the title clear about the environment, template, and symptom—for example, “Chinese verification email overflows horizontally in the staging mobile reading view.” Include the trigger time, delivery time, address domain, browser, expected result, and actual result in the body.
Never paste real verification codes, complete receiving addresses, or user email content into a public bug tracker. When sharing samples, use purpose-built test data and redact tokens.
When to switch to continuous forwarding tests
Temporary email works well for one-off build acceptance. Multi-day regression tests, delivery status checks, and attachment retries are better suited to a dedicated forwarding identity. It can keep an entry point active without exposing a QA team member’s real public email address.
Whatever identity you use, don’t treat a temporary email service as a load-testing target. Frequent automated requests can trigger rate limits and make the results meaningless for real users.