Hur du väljer ett test-e-postkonto för QA

Vad är ett test-e-postkonto för QA?

Ett test-e-postkonto, eller en test-e-postadress för QA, är en adress som ditt team använder för att ta emot och granska de mejl som din egen applikation skickar. Använd en tillfällig inkorg för manuella registrerings- och OTP-kontroller som inte är känsliga. Välj en företagsbrevlåda när meddelanden ska sparas, när du behöver kunna svara eller hantera bilagor, och en SMTP-sandlåda eller ett hostat inkorgs-API när automatiserade tester måste granska e-post utan att någon person är inblandad.

Tmailor driver den här bloggen, så här passar tjänsten in. Tmailor är en gratis tillfällig mejltjänst som bara tar emot e-post, på webben, Android, iOS och som en Telegram-bot. Den passar det första fallet: en person öppnar en inkorg, utlöser en registrering och läser vad som kommer in. För det sista fallet låter det separata Tmailor Temp Mail API automatiserade tester skapa adresser som bara tar emot e-post och läsa deras meddelanden från koden. Meddelanden finns kvar cirka 24 timmar från ankomst, bilagor tas inte emot och adressen kan inte skicka eller svara. Om du är ny på tillfälliga inkorgar, börja med hur tillfällig e-post fungerar.

• Inget mejl behöver komma fram (formulärvalidering, fixtures, enhetstester): använd en reserverad exempeldomän.
• En person läser mejlet och inget i det är känsligt: en tillfällig inkorg är det snabbaste alternativet.
• Känsliga uppgifter, svar, bilagor eller bevis som du måste behålla: använd en godkänd brevlåda som företaget kontrollerar; lägg bara till plustaggar om ditt e-postsystem och din applikation stöder dem.
• Ingen person som bevakar: använd en SMTP-catcher om du styr appens inställningar för utgående e-post, eller ett hostat inkorgs-API om appen måste skicka via sin vanliga leverantör.

Manuell kontra automatiserad e-posttestning: ett beslutsträd

Fyra frågor avgör vilket test-e-postkonto en kontroll behöver: om ett mejl överhuvudtaget måste komma fram, om en person eller kod läser det, om det innehåller känsliga uppgifter och om du styr vart applikationen skickar sin utgående e-post.

1. Behöver testet att ett mejl kommer fram? Formatkontroller, UI-tillstånd, fixtures och enhetstester brukar inte göra det. Använd adresser på example.com, example.org eller example.net. Dessa domäner är reserverade för dokumentation och exempel, så inget når en verklig person. Undvik att hitta på slumpmässiga domäner, eftersom någon kan äga dem.
2. Kommer en person att läsa meddelandet under testet? Smoke-tester, manuell UAT, demonstrationer och utforskande sessioner har en människa med i loopen. Regressionssviter och CI-jobb brukar inte ha det.
3. Om en person läser det, är något i det känsligt? Riktiga kundregister, inloggningsuppgifter, reglerade uppgifter eller meddelanden som du måste behålla som revisionsbevis hör inte hemma i en tillfällig inkorg. Använd en företagsbrevlåda i stället. Om svaret är nej räcker en tillfällig inkorg.
4. Om kod läser det, kan testmiljön skicka sin e-post till en test-SMTP-server? Om ja fångar en SMTP-catcher varje meddelande utan att leverera det. Om nej, eftersom appen måste skicka via sin vanliga e-postleverantör, använd en hostad inkorg som dina tester läser via ett API.

Tabellen jämför de fem alternativen sida vid sida.

Vilka adresser bör ett e-postfält acceptera eller avvisa?

Testa formulärvalidering separat från meddelandeleverans. Använd en reserverad adress som user@example.com för ett giltigt fall som aldrig levereras, inkludera en adress med en plustagg och en med en underdomän, och lägg till felaktiga fall som en saknad lokal del eller en saknad domän. Håll de förväntade resultaten i linje med den validator som ditt produktionssystem faktiskt använder.

När en tillfällig inkorg räcker

En tillfällig inkorg fungerar när en person kontrollerar ett flöde i taget och meddelandet inte innehåller något du skulle sakna efter en dag. Det är den klassiska användningen av en tillfällig e-postadress för QA: du behöver en e-postadress för att testa ett formulär för hand, inte ett långlivat konto. Typiska fall är ett röktest av registreringsformuläret före lansering, en manuell UAT-genomgång av ett nytt onboarding-mejl, en säljdemo av kontoskapande eller en utforskande session där du provar udda inmatningar och ser vad appen skickar.

Fördelen är snabbheten. Det finns inget konto att begära från IT och ingen delad brevlåda att städa upp. Avvägningen är kontrollen: du får ett kort meddelandefönster, inga bilagor och en inkorg som en person läser i stället för kod.

När du behöver en SMTP-catcher eller ett hostat inkorgs-API

När testerna körs utan tillsyn måste inkorgen kunna läsas av kod. Två typer av verktyg täcker det behovet, och de löser olika problem.

SMTP-catchers och sandlådor ersätter appens utgående e-postserver i en testmiljö och sparar varje meddelande för inspektion i stället för att leverera det.

• Mailpit är ett gratis verktyg med öppen källkod som du kör själv. Det fångar e-post som standard och erbjuder ett webbgränssnitt och ett REST API för integrationstester.
• MailHog fungerar på samma sätt men är äldre. Mailpits underhållare beskriver det som att det inte längre underhålls, så kontrollera dess status innan du inför det.
• Mailtrap Email Sandbox är en hostad version av samma idé, med SMTP- och API-åtkomst. Den är separat från Mailtraps produkt för produktionsutskick.
• Ethereal är en gratis falsk SMTP-tjänst som främst används med Nodemailer. Meddelanden fångas upp för förhandsgranskning och levereras aldrig.

Hostade inkorgs-API:er ger testerna riktiga adresser på leverantörens domäner, så din app skickar e-post via sin vanliga leverantör och testet läser resultatet via ett API. Tmailors eget Temp Mail API fungerar på detta sätt, med officiella SDK:er för Python, Node.js och PHP.

• Mailosaur erbjuder test-e-postadresser, ett API och klientbibliotek som fungerar med ramverk som Cypress, Playwright och Selenium. Tjänsten hanterar även SMS-koder.
• MailSlurp skapar inkorgar på begäran via sitt API och sina SDK:er. Tester kan vänta på ett meddelande och sedan plocka ut koder, länkar och bilagor.

Leverantörers funktioner och planer ändras, så bekräfta aktuella uppgifter på varje officiell webbplats innan du binder en testsvit till en av dem.

När en företagsbrevlåda med plustaggar är det bättre valet

Plustaggar gör att en företagsbrevlåda kan ta emot många olika adressvarianter. E-post till qa+signup eller qa+reset på din företagsdomän hamnar i qa-brevlådan, där du kan filtrera efter tagg. Google Workspace stöder detta, och Microsoft dokumenterar att plusadressering i Exchange Online är påslaget som standard om inte en administratör stänger av det.

Använd den här vägen när ett flöde innehåller verklig kunddata, pågår längre än en dag, behöver svar eller bilagor, eller ger bevis som en revisor kan begära. Tänk på begränsningarna. Taggar är varianter av en och samma brevlåda, inte separata inkorgar, så parallella tester kan läsa varandras meddelanden. Vissa registreringsformulär avvisar plustecknet, och vissa appar behandlar taggade varianter som samma konto. Båda beteendena är värda ett eget testfall.

Så kör du ett manuellt registreringstest med en tillfällig inkorg

Ett manuellt registreringstest som använder tillfällig e-post för testning kräver tre saker: en ny adress, bygget du testar och en plats utanför inkorgen där du registrerar vad som kom in. Kör det endast mot system som du äger eller har behörighet att testa.

1. Öppna en inkorg. Skapa en gratis tillfällig inkorg på webben, eller använd Tmailor-appen eller Telegram-boten och kopiera adressen. På en dator kan Tmailors webbläsartillägg även fylla i den i e-postfältet i din testversion.
2. Registrera dig i din testversion. Använd adressen i din staging- eller QA-miljö och notera tiden då du skickade in formuläret.
3. Håll utkik efter e-postmeddelandet. Kontrollera vilket meddelande som kom, avsändarens namn och From-adress, ämnesraden och hur lång tid det tog.
4. Slutför steget. Klicka på länken eller ange koden. Bekräfta att kontot ändrar status en gång och att återanvändning av samma länk misslyckas med ett tydligt meddelande.
5. Spara bevisen någon annanstans. Kopiera länken, koden, tidsstämplarna och en skärmbild till ditt testfall. Meddelanden finns kvar cirka 24 timmar från ankomst, så inkorgen är inte din testdokumentation.
6. Spara access token om du ska testa igen. Med token kan du senare öppna samma adress igen, till exempel för att köra en lösenordsåterställning på nytt. Den återställer inte meddelanden som redan har gått ut, och en förlorad token kan inte återställas.

När en session behöver flera personas samtidigt, till exempel en gratis användare, en provanvändare och en inbjuden lagkamrat, håller vyn med flera inkorgar upp till fem adresser sida vid sida i en och samma webbläsarflik. Varje persona får sin egen adress, så du kan se vilken e-postadress som tillhör vilket konto.

Den här vyn är fortfarande manuell. Inkorgarna skapas av en person i en webbläsare, inte av kod, så den ersätter inte ett hostat inkorgs-API för parallella obevakade körningar.

En inkorg eller en adress per test?

En enda delad inkorg räcker för en snabb rök­kontroll, men den blir snabbt rörig. När flera tester körs samtidigt gör liknande ämnesrader det svårt att avgöra vilket e-postmeddelande som hör till vilket skript, och felsökningen blir rena gissningsleken.

En adress per testfall löser det. Loggar, skärmdumpar och mejl stämmer överens, och ett saknat meddelande pekar på ett scenario i stället för alla. Guiden till att köra flera tillfälliga e-postinkorgar går igenom det arbetsflödet mer i detalj.

Vissa flöden kräver samma adress igen flera dagar senare, till exempel en provperiod som konverterar eller en användare som kommer tillbaka efter att ha slutat. En återanvändbar tillfällig e-postadress håller adressen tillgänglig via sin Access Token, men inte själva e-posten. Spara länkarna och koderna du behöver när varje steg körs, och flytta alla steg som bygger på äldre meddelanden till en företagsinkorg. Om en testare loggar in på en gratis Tmailor-konto innan personaadresser skapas, sparas varje adress under Skapade e-postadresser, så en förlorad token betyder inte längre en förlorad adress.

Vad man ska kontrollera i registrerings- och onboardingmejl

Börja med en inventering av alla mejl som flödet kan skicka, och bestäm sedan vad varje test ska verifiera. Team upptäcker ofta extra mejl först när de dyker upp mitt i ett test, efter ett tillväxtexperiment eller en säkerhetsändring som lade till ett mejl som ingen hade dokumenterat.

Mejl i ett typiskt registreringsflöde

• Verifieringslänk eller engångskod
• Välkomstmejl och eventuell snabbstartssekvens
• Inloggning med magisk länk
• Lösenordsåterställning
• Ändring av e-postadress, skickad till både den gamla och den nya adressen
• Säkerhetsvarning vid ny enhet eller ny plats
• Påminnelser om registreringar som aldrig slutfördes

För varje mejl skriver du ner utlösaren, den förväntade tidpunkten och de villkor som ändrar den, till exempel plan, region eller språk. Sätt det tillåtna leveransfönstret utifrån produktens dokumenterade krav i stället för att anta en universell tröskel; ett omedelbart verifieringsmeddelande och en schemalagd välkomstsekvens kräver olika förväntningar. När dessa förväntningar finns har varje test något konkret att kontrollera mot.

Vad du ska verifiera i varje testmejl

• Avsändare och mottagare: Avsändarnamn och -adress, Reply-To och den exakta mottagaradressen.
• Ämne och brödtext: både HTML- och klartextversionerna, med korrekta namn, plandetaljer och språk.
• Länkar: destinationen och om den pekar mot rätt miljö. Ett staging-mejl som länkar till produktionen är en riktig bugg.
• Koder: format, längd, text om utgångstid och om den angivna utgångstiden stämmer med vad servern tillämpar.
• Tidpunkt: hur lång tid det tog innan meddelandet kom fram efter utlösaren.
• Bilagor: om ett flöde skickar en PDF eller faktura, testa det i en företagsbrevlåda eller ett testverktyg. Tmailor tar inte emot bilagor.

En varning om rendering. En tillfällig inkorg visar hur en webbvisare renderar din HTML. Den säger inget om hur samma e-post ser ut i Gmail, Outlook, Apple Mail, mörkt läge eller på en liten telefonskärm, så planera separata renderingskontroller om det spelar roll.

Flöden för e-postbyte och kontoåterställning

Återställningsflöden går sönder på mer diskreta sätt än registrering. Kontrollera att ett e-postbyte skickar en bekräftelse till den nya adressen och ett meddelande till den gamla, att en använd återställningslänk inte kan återanvändas, att en äldre återställningslänk slutar fungera när en nyare har skickats, och att en länk som öppnas på en andra enhet leder användaren till ett rimligt läge. OTP-flöden förtjänar en separat riskgenomgång; OTP-risklistan för QA och UAT täcker mätvärden, tidsfönster för omsändning och ägarskap.

Hur du testar OTP- och verifieringsfall i gränslandet

Testa OTP- och verifieringsflöden mot försenad leverans, omsändningar, utgångna och felaktiga koder samt länkar som öppnas på en annan enhet. Varje fall bör kontrollera både serverresultatet och meddelandet som visas för användaren. Kör bara dessa tester på system som du äger eller har tillstånd att testa. Bra OTP-tester bryter flödet med avsikt:

• Långsam ankomst: vänta innan du kontrollerar inkorgen och bekräfta att gränssnittet förklarar vad som händer och erbjuder ett tydligt sätt att skicka igen.
• Beteende vid omsändning: begär en andra kod och kontrollera om den första ogiltigförklaras eller fortfarande accepteras.
• Utgångstid: ange en kod efter dess angivna livslängd och bekräfta att felmeddelandet stämmer med vad som hände.
• Fel kod: bekräfta att försöksgränsen och texten om nedkylning är begriplig för en människa.
• Magiska länkar mellan enheter: begär en länk på en laptop, öppna den på en telefon och kontrollera var användaren hamnar.

För en bredare bild av vilka koder som når en tillfällig inkorg och vilka som inte gör det, se den här guiden om tillfällig e-post för OTP-koder.

Om din produkt medvetet avvisar tillfälliga e-postdomäner bör du testa den vägen direkt. Bekräfta att avvisningsmeddelandet är tydligt och att en riktig eller företagskontrollerad adress fortfarande kan slutföra registreringen. Byt inte mellan andra tillfälliga domäner för att ta dig förbi blockeringen, varken på din egen produkt eller någon annans. Att bekräfta att blockeringen fungerar är testet; att kringgå den är det inte. Den här förklaringen om varför webbplatser blockerar tillfälliga e-postdomäner går igenom orsakerna bakom dessa filter.

Vad förändras när e-posttester körs utan tillsyn

När ingen person övervakar behöver testet en inkorg som det kan läsa via kod. Det innebär ett SMTP-catchers API eller ett hostat inkorgs-API. Tmailors webbinkorg är inte det verktyget, men Tmailor Temp Mail API är det: tester kan skapa adresser som bara tar emot, lista och läsa meddelanden och hämta engångskoden eller verifieringslänken som API:et hittar. En MCP-server låter AI-agenter som Claude, Cursor eller VS Code Copilot göra samma sak för registreringsflöden som du äger eller har tillstånd att testa.

Några vanor håller obevakade e-posttester stabila, oavsett vilket verktyg du väljer:

• Ge varje testkörning en egen adress och ett korrelations-ID, så att ett sent mejl från en tidigare körning inte kan uppfylla fel påstående.
• Använd en dedikerad väntan på att e-postmeddelandet ska anlända med rimlig backoff, separat från testets totala tidsgräns, och logga hur lång tid varje meddelande tog.
• Matcha det exakta meddelandet efter mottagare och ämne i stället för att läsa "det senaste mejlet".
• Maskera koder och magiska länkar i CI-loggar, eftersom loggar ofta lever längre än inkorgen.

Var också tydlig med vad ett godkänt test bevisar. "Appen genererade och skickade iväg e-postmeddelandet", "en hostad testdomän tog emot det via offentlig e-postinfrastruktur" och "Gmail placerade det i inkorgen, inte i skräpposten" är tre olika fakta. En SMTP-catcher bevisar det första, ett hostat inkorgs-API bevisar de två första, och ingen av dem bevisar det tredje. För pipeline-konfiguration på GitHub Actions, GitLab CI och CircleCI, se guiden till e-posttestning i CI/CD-pipelines.

Håll testdata säkra och håll dig inom reglerna

Använd syntetiska identiteter och icke-känsligt innehåll i tillfälliga testinkorgar, och kör registreringstester endast mot system som du äger eller har tillstånd att granska. Håll QA-konton borta från produktionsanalys, respektera hastighetsgränser och flytta reglerad data, inloggningsuppgifter, bilagor och bevarad dokumentation till godkända företagskontrollerade system.

• Inga riktiga data i en tillfällig inkorg. Skicka aldrig riktiga kundregister, inloggningsuppgifter, API-nycklar eller reglerad data till en tillfällig e-postadress. Använd syntetiska användare med uppenbart falska namn.
• Testa bara det du har tillstånd att testa. Kör registreringstester mot din egen produkt eller ett system som du har tillstånd att testa, och respektera tjänstens hastighetsgränser och villkor. Använd inte tillfällig e-post för att skapa konton i bulk på tredjepartswebbplatser. Volym- och belastningstester hör hemma i din egen staging-miljö, med en SMTP-catcher eller ett hostat inkorgs-API.
• Håll QA-trafiken borta från produktionssiffrorna. Märk testkonton tydligt och uteslut dem från analys- och tillväxtdashboards. Undvik att skicka stora mängder testpost från din produktionsdomän, där studsar och klagomål kan skada dess rykte.
• Skriv ned policyn. Ange vilka flöden som får använda en tillfällig inkorg, vilka som behöver en företagsbrevlåda, hur länge testdata sparas och vem som har åtkomst. Säkerhets- och efterlevnadsgranskningar går snabbare när gränserna redan finns på papper.

När säkerhetsavdelningen frågar hur en leverantör hanterar data bör du titta på vad den samlar in, hur länge den sparar meddelanden och hur åtkomsten fungerar. Den här översikten om tillfällig e-post och integritet tar upp dessa frågor ur användarens perspektiv. Beslutet om vilka flöden som får använda tillfälliga inkorgar ligger fortfarande hos dina egna juridiska, integritets- och säkerhetsteam.

Begränsningar att planera för

Tmailors webbinkorg passar för korta manuella kontroller av icke-känslig inkommande e-post (automatisering är vad Temp Mail API är till för). Innan du väljer den bör du avgöra om arbetsflödet behöver utgående åtgärder, bilagor, långlivade bevis eller varaktig återställning av adressen. Alla sådana krav kräver en företagskontrollerad brevlåda eller ett specialiserat testverktyg; checklistan nedan förklarar varför.

• Tmailor tar bara emot. Den kan kontrollera inkommande registrerings-, verifierings- och OTP-mejl, men inte svarsflöden eller något som skickas från adressen.
• Tmailor tar inte emot bilagor, så mejl med fakturor, kontrakt eller dokumentleveranser kräver en företagsbrevlåda eller ett testverktyg.
• Meddelanden finns kvar cirka 24 timmar från ankomst. Exportera de länkar, koder och tidsstämplar som en längre undersökning kommer att behöva.
• En access token öppnar en adress igen, men inte utgångna meddelanden, och en förlorad token kan inte återställas.
• Webbinkorgen läses av en person. Oövervakad läsning av inkorgen kräver en SMTP-catcher eller ett hostat inkorgs-API, till exempel Tmailor Temp Mail API.
• Vissa tjänster blockerar tillfälliga e-postdomäner. Om ett flöde du testar gör detta medvetet bör du verifiera det med en verklig eller företagskontrollerad adress.

Att välja rätt testinkorg

Välj inkorg utifrån vad testet måste bevisa. Använd en reserverad exempeldomän när leverans inte behövs, en tillfällig inkorg för manuella kontroller av icke-känsliga uppgifter, en företagsbrevlåda för flöden som ska sparas eller är känsliga, en SMTP-catcher när du styr inställningarna för utgående e-post och ett hostat inkorgs-API för obevakade end-to-end-tester.

För de manuella fallen, öppna en tillfällig inkorg och börja med registreringsflödet som du släpper härnäst. Tillfällig e-post har gott om praktiska användningsområden utöver QA också.