KC02 · Use case 03 · QA case file
Temporary email for testing: build a case, not a pile of messages.
The green toast says “Email sent.” A message appears in the inbox. The test passes. Then a real user clicks the link and lands on the wrong environment. The email test did not fail because nobody tested the email. It failed because the team tested only its existence.
Case 001 · false green
What does “the email test passed” actually mean?
If the assertion is only message exists, you have proved delivery to one observed inbox. You have not proved that the right user received it, that the template contains the right data, that the OTP is current, that the link points to the right host, or that the action changes application state.
QA becomes useful when every email is treated as evidence inside a larger user journey. A temporary inbox helps because it can give that evidence a clean owner: one short-lived test identity, one scenario, one receiving boundary.
Evidence board
Six questions before you mark the case PASS.
Identity
Which test account and recipient own this run?
Trigger
What exact action should have produced the email?
Envelope
Did the expected sender, recipient and subject arrive?
Payload
Is the content, locale, code or link correct for this case?
Action
Does the user-facing code or link behave as intended?
Outcome
Did the application reach the state the test actually promised?
The suspect list
Three inbox habits create convincing lies.
The immortal shared inbox
Yesterday's verification email sits beside today's. Two testers trigger the same subject. Someone clicks the newest-looking link and the scenario passes for the wrong reason. Fresh scenario-scoped recipients reduce that ambiguity.
Resend panic
The message is late, so the tester clicks Resend three times. Now four attempts can exist, server-side validity may have changed, and “the code doesn't work” no longer identifies which code was tested. Trigger deliberately; record the attempt.
Inbox-only assertions
A correct email can still lead to a broken verification, login or recovery transition. Finish the public action and inspect the destination state instead of awarding PASS inside the mailbox.
A clean test run
Open the case with a fresh identity.
Define the promised outcome
Write what the user should be able to do at the end. “Receive mail” is usually an intermediate checkpoint.
Create a disposable test recipient
Use synthetic, non-sensitive data and a fresh address when the scenario depends on first-time identity or clean message history.
Trigger one known event
Signup, invitation, confirmation or another authorized test action. Record roughly when it happened.
Inspect before acting
Match recipient, sender, subject, content, environment and the current code/link before using it.
Complete the user's handoff
Use the expected public action rather than replacing the interesting part of the test with a database shortcut.
Close with state
Verify the account, session, onboarding or product state that should follow, then stop carrying this test's inbox into unrelated cases.
Test matrix
Change one condition. Ask what evidence should change with it.
The boundary
Temporary email isolates a recipient. It does not make the test deterministic.
External delivery can be asynchronous. A clean inbox helps you know which scenario owns a message, but it cannot prove that every sender, network path or receiving service will deliver at a fixed speed. Separate ownership failures from timing failures when you investigate.
Use Case 03 owns the testing strategy
When should QA use a fresh disposable recipient? What evidence makes a run trustworthy? What creates false greens? Those are this page's questions.
KC03 owns the protocol details
OTP expiry, magic-link sessions, password-reset semantics, verification state, parallel E2E isolation and polling versus realtime each keep their dedicated technical article instead of being duplicated here.
Open Developer & QA articlesStart the next QA case with an empty evidence board.
Create a fresh MailOnce recipient for an authorized low-risk test, trigger one flow, and follow the evidence beyond the inbox.