The happy path proves that one user can register. Negative tests examine whether the application remains consistent when messages arrive late, actions are repeated or the user changes the address midway through signup.
Define expected behavior first
| Scenario | Question to answer |
|---|---|
| Expired verification link | Is the account unchanged and a supported next step offered? |
| Reused link | Does repeating the action avoid granting unintended access? |
| Second verification requested | Which link remains valid under the product's policy? |
| Address edited before confirmation | Can the earlier message still affect the wrong address? |
| Different signed-in account | Is the confirmation bound to its intended account? |
Use controlled identities
Run these checks only against your own application or within an authorized review. Create synthetic accounts with no customer data. Use inbox access controls appropriate for the verification links being tested.
Inspect both the page and stored state
A success message in the browser is not enough. Check the account's verification state through your supported test tooling. Likewise, an error page should not leave a partly applied update that changes later behavior.
Keep evidence safe
Report the sequence, build version and sanitized identifiers. Do not paste live tokens into shared issue titles or logs. Remove the synthetic accounts and invalidate remaining test links when the test ends.