De flesta riktiga produkter är i grunden multianvändare — team, arbetsytor, roller, inbjudningar. Ska du testa de flödena på riktigt behöver du flera distinkta, nåbara inkorgar samtidigt. En tillfällig e-post blir i det tysta ett av de mest användbara verktygen i en testares verktygslåda — och det har inget att göra med att gömma sig från skräppost.
Varför en enda inkorg inte räcker
Din egen adress finns redan i systemet, så du kan inte simulera en helt ny användare — än mindre tre olika nya användare samtidigt. Många team tar till ett delat QA-Gmail-konto med plus-adressering (t.ex. [email protected]). Det fungerar tills det inte gör det: en hel del appar tar bort eller nekar "+"-taggen, och även när den accepteras hamnar alla meddelanden ändå i samma brevlåda som du sedan måste reda ut för att se vilken "användare" som fått vad.
Arbetsflödet med tillfälliga inkorgar
Varje flik på temp-email.ai/temp-mail är en helt fristående inkorg med en egen unik adress. Öppna några flikar så har du flera riktiga användare du kan skicka till och ta emot från — inget konto att skapa, ingen delad brevlåda att städa upp efteråt. Allt raderas automatiskt efter en timme, så du sitter inte kvar med en hög testkonton kopplade till din personliga e-post.
Scenarier värda att testa
- Team- och arbetsytainbjudningar: varje inbjudan måste nå rätt adress med en fungerande länk, och att acceptera den ska släppa in personen i rätt arbetsyta med rätt roll.
- Roller och behörigheter: registrera en ägare, en admin och en läsbehörig medlem som tre separata användare, och bekräfta sedan att var och en ser — och inte ser — precis det som deras roll tillåter (se OWASP Authorization Cheat Sheet).
- Hantering av dubbletter: registrera två konton med olika adresser, försök sedan återanvända en av dem och se hur appen reagerar — även samma adress med olika skiftläge.
- Referral- och belöningsflöden: den som bjuder in ska bara krediteras när personen som bjudits in registrerar sig och verifierar sin adress — du behöver två aktiva inkorgar för att se båda sidorna utlösas.
- Isolering mellan tenants: skapa konton i två separata organisationer och bekräfta att en tenants data aldrig dyker upp i den andras mejl eller notiser — något som även NIST:s riktlinjer för multi-tenant-säkerhet tar upp.
- Samtidiga registreringar: registrera flera användare inom samma sekund för att fånga race conditions i tokengenerering och verifieringsmejl som dyker upp mycket senare än andra.
Vad du ska kolla när mejlet kommer fram
- Rätt mottagare: gick inbjudan bara till den avsedda adressen?
- Rätt länk: pekar accept-/verifieringslänken mot rätt miljö, med rätt arbetsyta och rollkontext — och inte en hårdkodad produktionslänk?
- Rätt slutresultat: hamnar användaren, efter att ha accepterat, i rätt organisation med precis de behörigheter som rollen ska ha?
- Rendering och isolering: renderas mejlet korrekt (klickbara knappar, rätt ifyllt namn), och refererar det aldrig av misstag till en annan användares uppgifter?
Den här metoden passar bäst för utforskande testning och den manuella regressionsgenomgången inför en release — på ett par minuter kan du sätta upp en liten, realistisk uppsättning användare och gå igenom produkten precis som ett riktigt team skulle göra. Två ärliga påpekanden: en del appar blockerar kända domäner för tillfälliga e-postadresser vid registrering, vilket helt enkelt är den appens egen policy, och det är värt att göra en sista genomgång med en riktig brevlåda som Gmail innan lansering, eftersom leveransrelaterade egenheter bara visar sig hos riktiga leverantörer. Använda på det här sättet är tillfälliga inkorgar ett enkelt och ärligt sätt att testa flöden med flera användare grundligt innan riktiga användare någonsin stöter på buggarna.