Test each flow with a separate address:
resends, expiration, and concurrency

This workflow is intended for product environments you are authorized to test. The goal is not bulk registration, but clear one-to-one mapping between each test identity, email, and result so issues can be reproduced quickly.

1. Start by mapping an identity matrix

Assign addresses by flow, not by tester. Use a separate address for normal sign-up, the first resend, expired links, language switching, and mobile reading. Create a new identity when repeating the same flow in another browser. This prevents a result from an earlier run being mistaken for the current one, even when messages arrive out of order.

In the RelayTmp disposable inbox, copy the address and record it in the case row immediately. Addresses have a clear default countdown, making them suitable for integration tests completed within a few hours. If testing spans several weeks or requires ongoing delivery to the same public identity, use a mailbox you control long term or a forwarding alias.

Recommended minimum QA matrix

Case	Separate identity	Key assertion
First sign-up	Address A	One email, valid code, matching welcome page
Code resend	Address B	Clear cooldown; old-code behavior matches the specification
Confirmation link expiration	Address C	Expiration page is clear and offers a way to retry
Language switching	One address per language	Subject, body, and link destination use the same language
Mobile reading	Address D	Code, buttons, and body text are not clipped

2. Run a clean baseline case first

Start from a clean session with no login state or autofill. After submitting the sign-up form, record the page feedback and trigger time. Do not switch addresses immediately or edit the account details before the email arrives. When it appears, verify the sender, subject, recipient, brand name, code format, and expiration notice.

When opening the confirmation link, check the destination domain and HTTPS, then return to the original page to confirm that the status is synchronized. Try opening the same link a second time: an idempotent link should retain the confirmed result, while a one-time link should show a clear used status rather than an obscure server error. Once the baseline passes, move on to disruptive paths such as resends and expiration.

3. Treat code resends as a state-machine test

Do not click repeatedly after the first send. Confirm that the button enters a 60-second cooldown or the waiting state defined by the product, then trigger the second send after the countdown ends. Record the arrival order, codes, and expiration times for both emails, then submit the old code and the new code in turn.

The server-side rules are the key details to document. If generating a new code immediately invalidates the old one, the old code should return a precise error. If both are allowed briefly, calculate each code’s expiration separately. The page must not rely only on a disabled button, because a refresh or another tab may trigger the request again. Server-side rules must enforce concurrency control.

• When clicking repeatedly in the same tab during cooldown, is only one task created?
• Does the cooldown remain after refreshing the page?
• When two tabs are clicked at the same time, are multiple valid codes created without an understandable explanation?
• When emails arrive out of order, does the interface say which code to use?
• Is there a recovery path after the maximum number of errors is reached?

4. Test code and link expiration on both sides of the boundary

Do not wait until something is “clearly expired” before clicking. Test once one minute before the deadline and again shortly after it to confirm that the clock boundary matches the copy. The device clock must not determine whether the server accepts a code; if it is still accepted after changing the local clock, validation may be happening in the wrong place.

The expiration page should explain what to do next: where to return, whether a resend is available, and whether the email address must be entered again. If a resend creates a new link, the old link must be invalidated according to the defined policy. Disposable inboxes also expire, so extend the mailbox before waiting for a long period; otherwise, you may mistake an expired test inbox for an expired product link.

5. Multilingual testing goes beyond translating the body

Create a separate address for each language and switch the product language before triggering the flow. Check that the subject, preheader, body, button, and footer all come from the same language pack; do not accept a mixed result such as an English subject with a Chinese body. Dates, time zones, and number formats should also follow the target language’s conventions.

Links must preserve the language context. A confirmation button in a Chinese email should not open an English error page, and a resend notice must not fall back to the default language. Test long French or Portuguese button labels at common mobile widths, and watch for unnatural spacing and line breaks in Japanese copy. Do not overlook the plain-text fallback just because the HTML template works.

6. Create records that support the next regression run

A good record is not a collection of screenshots; it is a reproducible procedure. Each row should include the precondition, address ID, trigger action, expected result, actual result, four key timestamps, and an evidence link. After a failure, revalidate with a new address unless you are specifically testing recovery for the same identity.

After completion, delete the test data and remove temporary addresses from any long-term account recovery settings. The advantage of a disposable inbox is a clear task boundary; if you still depend on it to recover an account after testing ends, the identity strategy has drifted from its purpose.

Run the first test case

Create an identity unaffected by old messages

Copy the address, trigger sign-up, and refresh the inbox. Use the first result as the baseline for later edge-case flows.

Create a test mailbox