Developer & QA checklist
Receiving an email is only the beginning. Use this checklist to verify business triggers, recipient identity, content hierarchy, calls to action, timing, failure paths, and privacy boundaries so release decisions are reproducible.
Coverage
These cards are not decoration. Work from left to right in test order, and never approve a blocked check just by sending the email again.
Before testing, document who did what, and in which state, then list the conditions that should and should not send an email. Testing only the happy path misses important branches such as disabled notifications, already-verified accounts, and duplicate-event handling.
Copy the recipient address from the current test toolbar instead of typing it manually. When you change the address, update the test user as well: old messages do not migrate, and mixing old and new addresses undermines trustworthy results.
Check code length, character set, validity period, one-time use, and resend rules. If the page says 10 minutes but the backend expires the code after 5, that is a product defect—not a minor copy issue.
Also test feedback for invalid and expired codes, repeated entry, and frequent resends. For link-based verification, check the protocol, hostname, environment, one-time token, and final page after the redirect; do not stop at confirming that the button works.
In the email body, verify container width, heading wraps, button height, paragraph spacing, and image scaling. Long names, project names, and French or Portuguese button labels are more likely than Chinese to break the layout, so regress with the longest reasonable samples.
With images disabled, the brand and core task should remain recognizable. The plain-text version should retain the code, expiry, links, and support details. Do not put everything in an image or let hidden preview text appear as the first line of the body.
Open the primary button, secondary links, help entry, and unsubscribe link one by one. Confirm the domain, path, parameters, and login state are correct. Test-environment links must not accidentally trigger production writes, and production templates must not contain test domains.
Check attachment names, types, sizes, and permissions; block or quarantine dangerous types. When replying, verify that Reply-To reaches the intended support channel rather than an unmonitored sending address.
The subject, preview, body, buttons, and error messages must use the same language. Format dates, amounts, and time zones for the user's locale. If a translation is missing, use a controlled fallback instead of mixing languages at random in one email.
Heading levels should be sequential, link text should describe its purpose, and images should have suitable alt text. Color must not be the only way to convey status; light text on white and dark text on colored backgrounds both need sufficient contrast.
Simulate queue delays, temporary provider rejections, and permanent bounces. Check that retries follow policy without creating duplicate notifications. The UI should provide actionable statuses instead of labeling every failure a network error.
If a test email does not arrive, diagnose it layer by layer using evidence from the app, queue, sending platform, DNS, and receiving end. Preserve evidence of the first failure, then verify the fix; do not delete the original trail just because a resend succeeds.
| Level | Example | Release gate | Failure handling |
|---|---|---|---|
| Blocker | Email not generated, wrong recipient, unusable code, incorrect primary link | All checks must pass | Stop the release and fix the root cause |
| High | Duplicate send, inconsistent expiry, mobile body clipped | Fix it or obtain written acceptance from the owner | Set a clear deadline and regression case |
| Medium | Duplicate preview, unclear secondary-link labels, poor wrapping for long text | Assess audience and frequency | Schedule it for the next iteration and retain evidence |
| Low | Minor visual discrepancy that does not affect the task | Does not block the core flow | Record the template and client scope |
Record the case ID, environment, template version, language, recipient-address prefix, trigger and delivery times, message ID, result, and defect link. Screenshots should include the subject and key body content, with tokens and real personal data redacted.
After a fix, run the regression under the same conditions and add the nearest failure path. If you need help locating a delivery issue, use the email delivery diagnostics guide or contact support@msgtmp.com.
