← Blog

I Test Apps for a Living. My Inbox Situation Used to Be Embarrassing.

23 October 2026 · Developers

Somewhere on my laptop there's a spreadsheet with about forty rows in it. Username, password, which app, date created. Row twelve is my favourite: the password field just says "lost lol". Half those accounts were registered to my personal email, because at 2 a.m., mid-test-cycle, my personal email was the only inbox I had that actually worked.

I Test Apps for a Living. My Inbox Situation Used to Be Embarrassing. — illustration

That's the part of QA nobody warns you about. The testing itself is fine. It's the accounts. Every signup flow needs a fresh one, and fresh accounts need inboxes, and inboxes are where good intentions go to die.

Why test@test.com never works

Every junior tester tries the same shortcut first. You type test@test.com into the form, or asdf@asdf.com if you're feeling fancy, and hit register. The form accepts it, sometimes. Then the app does the one thing it was built to do: it sends a verification email. And that email goes nowhere, because test@test.com is not a real inbox anyone reads. Your test account sits there unverified, the flow you were supposed to check sits behind it, and you've learned nothing except that the form has loose validation.

The thing is, you can't fake the receiving end. A signup flow isn't really tested until a real email arrives in a real inbox and a real human (you, sadly) clicks the link or types the code. Half the bugs I've ever found in onboarding lived exactly there — codes that expired in thirty seconds, links that broke on mobile, emails that landed in spam with the subject line half cut off. You only see those when the mail is genuinely flowing.

I Test Apps for a Living. My Inbox Situation Used to Be Embarrassing. — illustration

So you start collecting inboxes like mugs

My first fix was making extra accounts with the big providers. That lasted about a week. Each one wants a phone number now, each one locks you out if you create accounts too enthusiastically, and after the third "suspicious activity" warning you start doing maths about how much of your life you're spending proving you're not a robot.

What actually works is dumber and better: use a temporary inbox for anything disposable. New flow to test? I open the free inbox tool on , generate an address, and the verification mail is sitting there in seconds. Test done, inbox expires, nothing follows me home. No spreadsheet row. No "lost lol".

I keep a couple of habits from the old days, though. If a flow involves a password reset, I test it in the same session, while the inbox is still alive — learned that one the hard way, obviously. And if a build sends codes that take five minutes to arrive, I note the inbox's expiry in the bug report, because a code that outlives the inbox looks exactly like a code that never came.

The accounts that do need to live

Not everything in testing is throwaway. Staging environments are the big exception. Our staging accounts have history — saved projects, billing states, half-finished onboarding — and the team shares them. Kill the inbox behind one of those and you've killed the account's password reset, which means you've killed the account, which means somebody (me) rebuilds the whole test fixture on a Monday.

Those get a permanent inbox instead. Same idea, no expiry, tied to my registered account so it's actually mine. I wrote a bit about how I split the two in my piece on the three-inbox system, but the short version is: temp for flows, permanent for fixtures. Anything else is just asking the spreadsheet to grow.

I Test Apps for a Living. My Inbox Situation Used to Be Embarrassing. — illustration

What I'd tell a new tester

Stop registering test accounts to things you care about. Your personal email is not a test resource; it's where your bank writes to you. The day a client's staging database leaks — and staging databases leak constantly, they're held together with hope — your address is in it, attached to forty half-finished accounts.

And read the guide on OTP safety before you get casual with codes. Testing makes you sloppy about verification codes because you see fifty a day. They're still keys. Treat them like keys even when they're fake keys to fake accounts, because habits don't check context before they fire.

If you're setting up your own testing routine, start stupidly simple: one temp inbox per flow, one permanent inbox per environment, and a spreadsheet you actually maintain. Mine still has that "lost lol" row in it. I keep it as a warning to myself.

Keep reading