A useful email test ends with evidence that the intended person can complete the intended action. Seeing a message appear is one checkpoint. You also need to know which request produced it, where its link goes, and what happens after the action succeeds or fails.
This worksheet is for people testing an application they own or have permission to assess. It expands our guide to testing email signup flows into a record you can copy into an issue or release checklist. The application, addresses, timings, and outcomes below are fictional examples, not results from tests of TempGenerator or another provider.
Write the acceptance rule before sending anything
Start with one sentence about observable behavior. For a fictional project called Orchard Notes, it might be: “A newly registered test user can verify the address they entered, and an expired verification link explains how to request a replacement.” Split that into separate cases. Otherwise, an arriving message can distract you from a broken destination or a confusing error.
Agree on the expected resend and expiry behavior with the application owner. Whether requesting another verification message invalidates the first link is a product decision that the test must name. Do not decide what should happen after seeing what the current code happens to do.
Copy this record for each run
- Run: a unique label, such as orchard-qa-042, plus the application version.
- Environment: the exact application hostname and sending configuration.
- Recipient: the full test address, recorded privately if necessary.
- Starting state: new account, unverified account, or existing verified account.
- Action and time: what you submitted and when, including the time zone.
- Expected result: the message, destination, and final account state.
- Observed result: what actually happened, with message time and a safe screenshot.
- Disposition: pass, fail, or blocked; owner and next check if unresolved.
Keep a blank observation field until you execute the case. “Expected: arrives” is not an observation. Record a blocked result when, for example, the test environment is unavailable. That leaves the acceptance question open without claiming the feature itself is broken.
A small matrix with specific evidence
| Case | Action | Evidence to record |
|---|---|---|
| Fresh verification | Register a new synthetic account. | Correct recipient and environment; successful action changes that account to verified. |
| Resend | Request a replacement after the permitted interval. | Which message belongs to each request; both links behave according to the agreed rule. |
| Expired link | Use a deliberately expired fixture in a controlled environment. | Account remains unverified; the page explains the next step. |
| Already completed | Reopen the verification link after success. | No extra account is created; the user sees a sensible completion state. |
| Different recipient | Run a second case with a separate test account. | Each message and action belongs only to its intended account. |
Password recovery needs its own cases. OWASP's password-reset guidance recommends single-use, expiring reset tokens and consistent request responses for existing and nonexistent accounts. Add checks for those properties when testing your own reset flow. A quick manual worksheet cannot establish that the full authentication system is secure.
Make the message easy to identify
In a controlled capture environment, use a synthetic address such as orchard-qa-042@example.test. That is an illustrative test address, not a mailbox for internet delivery. Put the run label into a test-only subject or other safe fixture field if your application supports it. For a real receiving check, use the actual address supplied by the inbox you control.
If you use Mailpit for local capture, its documented search filters support recipient and subject searches. A query such as to:orchard-qa-042@example.test subject:orchard-qa-042 helps isolate a fixture. Inspect the matched message as well; a search result alone does not prove that its link or recipient is correct.
TempGenerator can receive messages for a manual check, but it is not a permanent test archive or a sender. Its generated addresses are temporary. Read the actual inbox countdown and complete one case before changing the address. Use your own capture system when a test needs repeatable fixtures, parallel recipients, or retained evidence.
A worked result that catches a real kind of failure
Consider this invented observation: the signup form was submitted at 14:03:00 UTC, the message was visible at 14:03:12 UTC, and its button opened the production hostname instead of the staging hostname named in the test record. The tester stopped before completing the action.
The result is fail: wrong action destination. It is not “email passed.” The twelve-second observation also says nothing about typical delivery speed. A useful issue includes the run label, version, expected hostname, observed hostname, and a screenshot with the complete token removed. That gives a developer a concrete sending-template or configuration problem to investigate.
Close the run without keeping access secrets
Save the result and redacted evidence in your normal issue tracker before the inbox expires. Omit passwords, live codes, full verification URLs, and customer information. Record what the test established: perhaps the message rendered correctly in one browser and the intended account changed state. List any remaining checks, such as another mail client or the corrected destination. That boundary makes the result useful to the next person deciding whether to release.
