Jak si vybrat testovací e-mailový účet pro QA

Co je to testovací e-mailový účet pro QA?

Testovací e-mailový účet, neboli testovací e-mailová adresa pro QA, je adresa, kterou váš tým používá k přijímání a kontrole e-mailů, které odesílá vaše vlastní aplikace. Pro ruční kontroly registrací a OTP, které neobsahují citlivé údaje, použijte dočasnou schránku. Pro uchovávané zprávy, odpovědi nebo přílohy zvolte firemní poštovní schránku a v případě, že automatizované testy musí kontrolovat e-maily bez přítomnosti člověka, použijte SMTP sandbox nebo hostované API pro doručenou poštu.

Tento blog provozuje Tmailor, takže zde je jeho místo. Tmailor je bezplatná dočasná poštovní služba pouze pro příjem, dostupná na webu, Androidu, iOS a jako Telegram bot. Hodí se pro první případ: člověk otevře schránku, spustí registraci a přečte, co dorazí. Pro poslední případ umožňuje samostatné Tmailor Temp Mail API automatizovaným testům vytvářet adresy pouze pro příjem a číst jejich zprávy z kódu. Zprávy zůstávají přibližně 24 hodin od doručení, přílohy se nepřijímají a adresa nemůže odesílat ani odpovídat. Pokud s dočasnými schránkami začínáte, začněte tímto jak funguje dočasná pošta.

• E-mail vůbec nemusí dorazit (validace formulářů, fixtures, unit testy): použijte vyhrazenou příkladovou doménu.
• E-mail čte člověk a nic v něm není citlivé: dočasná schránka je nejrychlejší volba.
• Citlivá data, odpovědi, přílohy nebo důkazy, které musíte uchovávat používejte schválenou firemní schránku; Přidejte plus tagy jen pokud je váš poštovní systém a aplikace podporují.
• Nikdo to nesleduje: použijte SMTP catcher, pokud ovládáte nastavení odchozí pošty aplikace, nebo hostované API pro doručenou poštu, pokud aplikace musí odesílat přes svého běžného poskytovatele.

Ruční vs. automatizované testování e-mailů: rozhodovací strom

O tom, který testovací e-mailový účet daná kontrola potřebuje, rozhodují čtyři otázky: zda musí e-mail vůbec dorazit, zda jej čte člověk nebo kód, zda obsahuje citlivá data a zda ovládáte, kam aplikace odesílá odchozí poštu.

1. Potřebuje test, aby e-mail dorazil? Kontroly formátu, stavy uživatelského rozhraní, fixtures a unit testy obvykle ne. Používejte adresy na example.com, example.org nebo example.net. Tyto domény jsou vyhrazeny pro dokumentaci a příklady, takže se nic nedostane ke skutečnému člověku. Vyhněte se vymýšlení náhodných domén, protože je může někdo vlastnit.
2. Přečte si zprávu během testu člověk? Smoke testy, ruční UAT, ukázky a průzkumná sezení mají ve smyčce člověka. Regresní sady a úlohy CI obvykle ne.
3. Pokud ji čte člověk, je v ní něco citlivého? Skutečné zákaznické záznamy, přihlašovací údaje, regulovaná data nebo zprávy, které musíte uchovávat jako auditní důkazy, do dočasné schránky nepatří. Použijte místo toho firemní schránku. Pokud je odpověď ne, dočasná schránka stačí.
4. Pokud ji čte kód, může testovací prostředí odesílat svou poštu na testovací SMTP server? Pokud ano, SMTP catcher zachytí každou zprávu, aniž by ji doručil. Pokud ne, protože aplikace musí odesílat přes svého běžného e-mailového poskytovatele, použijte hostovanou schránku, kterou vaše testy čtou přes API.

Tabulka porovnává všech pět možností vedle sebe.

Které adresy by mělo e-mailové pole přijmout nebo odmítnout?

Validaci formuláře testujte odděleně od doručování zpráv. Pro případ, který vypadá platně, ale nikdy se nedoručí, použijte rezervovanou adresu, například user@example.com, přidejte adresu s plusovou značkou a adresu s poddoménou a doplňte chybné případy, jako je chybějící lokální část nebo chybějící doména. Očekávané výsledky udržujte v souladu s validátorem, který váš produkční systém skutečně používá.

Když stačí dočasná schránka

Dočasná schránka stačí, když člověk kontroluje jeden tok po druhém a zpráva neobsahuje nic, co by vám po dni nevadilo ztratit. To je klasické využití dočasného e-mailu pro QA: potřebujete e-mailovou adresu pro ruční testování formuláře, ne dlouhodobý účet. Typickými případy jsou předběžný smoke test registračního formuláře, ruční UAT nového uvítacího e-mailu, prodejní ukázka vytváření účtu nebo průzkumné sezení, kde zkoušíte neobvyklé vstupy a sledujete, co aplikace odešle.

Přitažlivá je rychlost. Nemusíte žádat IT o účet ani uklízet sdílenou schránku. Nevýhodou je omezená kontrola: máte krátké okno pro zprávy, žádné přílohy a schránku, kterou čte člověk, nikoli kód.

Když potřebujete SMTP catcher nebo hostované API pro schránku

Jakmile testy běží bez dozoru, musí být schránka čitelná pro kód. Tuto potřebu pokrývají dvě skupiny nástrojů a řeší různé problémy.

SMTP catchery a sandboxy v testovacím prostředí nahrazují odchozí poštovní server vaší aplikace a každou zprávu uchovají k prohlédnutí, místo aby ji doručily.

• Mailpit je bezplatný open-source nástroj, který provozujete sami. Ve výchozím nastavení zachytává poštu a nabízí webové rozhraní a REST API pro integrační testy.
• MailHog funguje stejně, ale je starší. Správci Mailpitu jej označují za již neudržovaný, proto si před jeho nasazením ověřte jeho stav.
• Mailtrap Email Sandbox je hostovaná verze stejného konceptu s přístupem přes SMTP a API. Je oddělený od produkčního odesílacího produktu Mailtrapu.
• Ethereal je bezplatná falešná SMTP služba používaná hlavně s Nodemailerem. Zprávy jsou zachyceny k náhledu a nikdy se nedoručí.

Hostovaná API pro schránky dávají testům skutečné adresy na doménách dodavatele, takže vaše aplikace posílá poštu přes svého běžného poskytovatele a test čte výsledek přes API. Tímto způsobem funguje i vlastní Temp Mail API od Tmailor, s oficiálními SDK pro Python, Node.js a PHP.

• Mailosaur nabízí testovací e-mailové adresy, API a klientské knihovny, které fungují s frameworky jako Cypress, Playwright a Selenium. Pokrývá také SMS kódy.
• MailSlurp vytváří schránky na vyžádání prostřednictvím svého API a SDK. Testy mohou počkat na zprávu a poté z ní vytáhnout kódy, odkazy a přílohy.

Funkce a tarify dodavatelů se mění, proto si předtím, než na některého navážete testovací sadu, ověřte aktuální podrobnosti na jeho oficiálním webu.

Kdy je firemní schránka s plusovými štítky lepší volbou

Plusové štítky umožňují jedné firemní schránce přijímat mnoho variant adresy. Pošta na qa+signup nebo qa+reset na vaší firemní doméně dorazí do schránky qa, kde ji můžete filtrovat podle štítku. Google Workspace to podporuje a Microsoft dokumentuje, že adresování s plusem v Exchange Online je ve výchozím nastavení zapnuté, pokud jej administrátor nevypne.

Tuto cestu použijte, když tok nese skutečná zákaznická data, běží déle než den, vyžaduje odpovědi nebo přílohy, nebo vytváří důkazy, které může auditor požadovat. Mějte na paměti omezení. Štítky jsou varianty jedné schránky, nikoli samostatné schránky, takže paralelní testy si mohou navzájem číst zprávy. Některé registrační formuláře odmítají znaménko plus a některé aplikace považují označené varianty za stejný účet. Obě chování si zaslouží vlastní testovací případ.

Jak provést ruční test registrace s dočasnou schránkou

Ruční test registrace, který k testování používá dočasný e-mail, potřebuje tři věci: novou adresu, testovanou verzi a místo mimo schránku, kam zaznamenáte, co dorazilo. Spouštějte jej pouze na systémech, které vlastníte nebo k jejichž testování máte oprávnění.

1. Otevřete schránku. Vytvořte si bezplatnou dočasnou schránku na webu, nebo použijte aplikaci Tmailor či bota na Telegramu a zkopírujte adresu. Na počítači vám může rozšíření prohlížeče Tmailor může adresu také vyplnit do e-mailového pole testované verze.
2. Zaregistrujte se ve své testované verzi. Použijte adresu ve svém stagingovém nebo QA prostředí a poznamenejte si čas, kdy jste formulář odeslali.
3. Sledujte, zda e-mail dorazí. Zkontrolujte, která zpráva dorazila, jméno odesílatele a adresu From, předmět a jak dlouho to trvalo.
4. Dokončete krok. Klikněte na odkaz nebo zadejte kód. Ověřte, že se stav účtu změní právě jednou a že opětovné použití stejného odkazu selže s jasnou zprávou.
5. Důkazy zaznamenejte jinde. Zkopírujte odkaz, kód, časová razítka a snímek obrazovky do svého testovacího případu. Zprávy zůstávají přibližně 24 hodin od doručení, takže schránka není vaším záznamem o testu.
6. Pokud budete testovat znovu, uložte si Access Token. Token později znovu otevře stejnou adresu, například pro opětovné spuštění resetu hesla. Neobnoví však zprávy, které už vypršely, a ztracený token nelze obnovit.

Když relace potřebuje několik person najednou, například uživatele zdarma, zkušebního uživatele a pozvaného kolegu, zobrazení více doručených postávek udrží až pět adres vedle sebe v jedné kartě prohlížeče. Každá persona má vlastní adresu, takže vidíte, který e-mail patří kterému účtu.

Toto zobrazení je stále ruční. Schránky vytváří člověk v prohlížeči, nikoli kód, takže nenahrazuje hostované API pro schránky při paralelních bězích bez dozoru.

Jedna schránka, nebo jedna adresa na test?

Jedna sdílená schránka stačí na rychlou orientační kontrolu, ale rychle se v ní udělá zmatek. Jakmile běží několik testů současně, podobné předměty zpráv ztěžují rozpoznání, který e-mail patří ke kterému skriptu, a ladění se mění v hádání.

Jedna adresa na testovací případ to vyřeší. Logy, snímky obrazovky a e-maily do sebe zapadnou a chybějící zpráva ukazuje na jeden scénář, ne na všechny. Průvodce provozováním více dočasných poštovních schránek tento postup podrobněji popisuje.

Některé cesty potřebují stejnou adresu znovu o několik dní později, například u zkušební verze, která přejde na placenou, nebo u uživatele, který se vrátí po odchodu. Znovupoužitelná dočasná e-mailová adresa udržuje adresu dostupnou prostřednictvím access tokenu, ale poštu ne. Ukládejte odkazy a kódy, které potřebujete, při každém kroku a každý krok, který závisí na starších zprávách, přesuňte do firemní schránky. Pokud se tester přihlásí do bezplatného účtu Tmailor před vytvořením adres person, každá z nich se uloží pod Created Emails, takže ztracený token už neznamená ztracenou adresu.

Co kontrolovat v e-mailech k registraci a onboardingu

Začněte soupisem všech e-mailů, které může daná cesta odeslat, a poté rozhodněte, co má každý test ověřovat. Týmy často objeví další e-maily až ve chvíli, kdy se objeví uprostřed testu, poté co růstový experiment nebo bezpečnostní změna přidaly nějaký, který nikdo nezaznamenal.

E-maily v typickém průběhu registrace

• Ověřovací odkaz nebo jednorázový kód
• Uvítací e-mail a případná sekvence rychlého startu
• Přihlášení pomocí magic linku
• Obnovení hesla
• Změna e-mailové adresy, odeslaná na starou i novou adresu
• Bezpečnostní upozornění na nové zařízení nebo nové místo
• Připomínky registrací, které nebyly nikdy dokončeny

U každého si zapište spouštěč, očekávané načasování a podmínky, které ho mění, jako je tarif, region nebo jazyk. Povolené okno doručení nastavte podle dokumentovaného požadavku svého produktu, místo abyste předpokládali univerzální prahovou hodnotu; okamžitá ověřovací zpráva a naplánovaná uvítací sekvence vyžadují odlišná očekávání. Jakmile tato očekávání existují, má každý test něco konkrétního, proti čemu lze ověřovat.

Co ověřovat v každém testovacím e-mailu

• Odesílatel a příjemce: jméno a adresa odesílatele, adresa Reply-To a přesná adresa v poli To.
• Předmět a tělo: verze HTML i prostý text, se správnými jmény, údaji o plánu a jazykem.
• Odkazy: cíl a zda vede do správného prostředí. E-mail ze stagingu, který odkazuje na produkci, je skutečná chyba.
• Kódy: formát, délka, text o platnosti a zda uvedená platnost odpovídá tomu, co vynucuje server.
• Časování: jak dlouho trvalo, než zpráva po spuštění dorazila.
• Přílohy: pokud nějaký tok posílá PDF nebo fakturu, otestujte to ve firemní poštovní schránce nebo v testovacím nástroji. Tmailor přílohy nepřijímá.

Jedno upozornění k vykreslování. Dočasná schránka ukazuje, jak vaše HTML zobrazuje jeden webový prohlížeč. Neřekne vám, jak stejný e-mail vypadá v Gmailu, Outlooku, Apple Mailu, v tmavém režimu nebo na malé obrazovce telefonu, takže pokud na tom záleží, naplánujte samostatné kontroly vykreslování.

Toky změny e-mailu a obnovy účtu

Toky obnovy selhávají nenápadněji než registrace. Zkontrolujte, že změna e-mailu odešle potvrzení na novou adresu a oznámení na starou, že použitý odkaz pro obnovení nelze znovu použít, že starší odkaz pro obnovení přestane fungovat po odeslání novějšího a že odkaz otevřený na druhém zařízení dostane uživatele do rozumného stavu. Toky OTP si zaslouží samostatné posouzení rizik; kontrolní seznam rizik OTP pro QA a UAT pokrývá metriky, intervaly pro opětovné odeslání a vlastnictví.

Jak testovat okrajové případy OTP a ověřování

Testujte toky OTP a ověřování se zpožděným doručením, opětovným odesláním, prošlými a nesprávnými kódy a odkazy otevřenými na jiném zařízení. Každý případ by měl ověřit jak výsledek na serveru, tak zprávu zobrazenou uživateli. Tyto testy provádějte pouze na systémech, které vlastníte nebo k jejichž testování máte oprávnění. Dobré testy OTP tok záměrně narušují:

• Pomalé doručení:: počkejte s kontrolou doručené pošty a ujistěte se, že uživatelské rozhraní vysvětluje, co se děje, a nabízí jasný způsob opětovného odeslání.
• Chování při opětovném odeslání: vyžádejte si druhý kód a zkontrolujte, zda je první kód zneplatněn, nebo je stále přijímán.
• Platnost: zadejte kód po uplynutí uvedené doby platnosti a ověřte, že chybová zpráva odpovídá tomu, co se stalo.
• Nesprávný kód: ověřte, že limit pokusů a text o čekací době dávají člověku smysl.
• Magické odkazy mezi zařízeními: vyžádejte si odkaz na notebooku, otevřete ho v telefonu a zkontrolujte, kam se uživatel dostane.

Pro širší přehled o tom, které kódy do dočasné schránky dorazí a které ne, si přečtěte tento průvodce pro dočasnou poštu pro OTP kódy.

Pokud váš produkt záměrně odmítá domény pro dočasnou poštu, otestujte tuto cestu přímo. Ověřte, že zpráva o odmítnutí je srozumitelná a že registraci stále dokončí skutečná adresa nebo adresa pod kontrolou firmy. Nepřecházejte na jiné dočasné domény, abyste blok obešli, ať už u svého produktu, nebo u kohokoli jiného. Ověření, že blok funguje, je test; jeho obejití test není. Tento vysvětlující článek o proč weby blokují dočasné poštovní domény, pokrývá důvody těchto filtrů.

Co se změní, když e-mailové testy běží bez dozoru

Když se nikdo nedívá, test potřebuje schránku, kterou dokáže číst prostřednictvím kódu. To znamená API SMTP catcheru nebo hostované API pro doručenou poštu. Webová schránka Tmailor tímto nástrojem není, ale Tmailor Temp Mail API ano: testy mohou vytvářet adresy pouze pro příjem, vypisovat a číst zprávy a získat jednorázový kód nebo ověřovací odkaz, který API najde. MCP server umožňuje AI agentům, jako jsou Claude, Cursor nebo VS Code Copilot, dělat totéž pro registrační toky, které vlastníte nebo které smíte testovat.

Několik návyků udrží e-mailové testy bez dozoru stabilní, ať už zvolíte jakýkoli nástroj:

• Každému spuštění testu dejte vlastní adresu a korelační ID, aby pozdní e-mail z předchozího běhu nemohl splnit nesprávnou podmínku.
• Použijte vyhrazené čekání na příchod e-mailu s rozumným odstupem mezi pokusy, oddělené od celkového časového limitu testu, a zaznamenávejte, jak dlouho každá zpráva trvala.
• Párujte přesně konkrétní zprávu podle příjemce a předmětu, místo abyste četli „nejnovější e-mail“.
• Maskujte kódy a magické odkazy v protokolech CI, protože protokoly často přežijí schránku.

Také si ujasněte, co úspěšný test dokazuje. „Aplikace e-mail vygenerovala a předala“, „hostovaná testovací doména jej přijala přes veřejnou e-mailovou infrastrukturu“ a „Gmail jej zařadil do doručené pošty, ne do spamu“ jsou tři různé skutečnosti. SMTP catcher dokazuje první, hostované API pro doručenou poštu dokazuje první dvě a ani jedno nedokazuje třetí. Pro nastavení pipeline na GitHub Actions, GitLab CI a CircleCI viz průvodce testování e-mailů v CI/CD pipeline.

Udržujte testovací data v bezpečí a držte se pravidel

V dočasných testovacích schránkách používejte syntetické identity a necitlivý obsah a registrační testy spouštějte pouze proti systémům, které vlastníte nebo k jejichž testování máte oprávnění. Držte QA účty mimo produkční analytiku, dodržujte limity požadavků a regulovaná data, přihlašovací údaje, přílohy a uchovávané důkazy přesouvejte do schválených systémů pod kontrolou firmy.

• Žádná skutečná data v dočasné schránce. Nikdy neposílejte skutečné zákaznické záznamy, přihlašovací údaje, API klíče ani regulovaná data na adresu dočasné pošty. Používejte syntetické uživatele s očividně falešnými jmény.
• Testujte jen to, co smíte testovat. Spouštějte registrační testy proti vlastnímu produktu nebo systému, který máte oprávnění testovat, a respektujte limity požadavků a podmínky dané služby. Nepoužívejte dočasnou poštu k hromadnému vytváření účtů na webech třetích stran. Zátěžové testování a testování objemu patří do vašeho vlastního testovacího prostředí se SMTP catcherem nebo hostovaným API pro doručenou poštu.
• Držte QA provoz mimo produkční čísla. Testovací účty jasně označte a vylučte je z analytiky a dashboardů růstu. Vyhněte se odesílání velkého množství testovací pošty z vaší produkční odesílací domény, kde mohou odrazy a stížnosti poškodit její reputaci.
• Zapište zásady. Uveďte, které toky mohou používat dočasnou schránku, které potřebují firemní schránku, jak dlouho se testovací data uchovávají a kdo k nim má přístup. Bezpečnostní a compliance kontroly probíhají rychleji, když jsou hranice už na papíře.

Když se bezpečnost ptá, jak poskytovatel nakládá s daty, podívejte se, co sbírá, jak dlouho uchovává zprávy a jak funguje přístup. Tento přehled dočasné pošty a online soukromí pokrývá tyto otázky z pohledu uživatele. Rozhodnutí o tom, které toky mohou používat schránky pro dočasnou poštu, však stále náleží vašim vlastním právním, soukromým a bezpečnostním týmům.

Limity, se kterými je třeba počítat

Webová schránka Tmailor se hodí pro krátké ruční kontroly necitlivých příchozích e-mailů (automatizace je úkolem Temp Mail API). Než ji zvolíte, rozhodněte se, zda pracovní postup potřebuje odchozí akce, přílohy, dlouhodobé důkazy nebo trvalé obnovení adresy. Každý z těchto požadavků vyžaduje firemní poštovní schránku nebo specializovaný testovací nástroj; kontrolní seznam níže vysvětluje proč.

• Tmailor je pouze pro příjem. Dokáže zkontrolovat příchozí registrační, ověřovací a OTP poštu, ale ne toky odpovědí ani cokoli, co se odesílá z dané adresy.
• Tmailor nepřijímá přílohy, takže e-maily s fakturami, smlouvami nebo doručením dokumentů vyžadují firemní schránku nebo testovací nástroj.
• Zprávy zůstávají přibližně 24 hodin od doručení. Exportujte odkazy, kódy a časová razítka, která bude delší vyšetřování potřebovat.
• Access token znovu otevře adresu, nikoli expirované zprávy, a ztracený token nelze obnovit.
• Webovou schránku čte člověk. Pro čtení schránky bez dozoru je potřeba SMTP catcher nebo hostované API pro doručenou poštu, například Tmailor Temp Mail API.
• Některé služby blokují domény pro dočasnou poštu. Pokud tok, který testujete, toto dělá záměrně, ověřte to skutečnou nebo firemní adresou.

Výběr správné testovací schránky

Schránku vybírejte podle toho, co má test prokázat. Použijte vyhrazenou ukázkovou doménu, když není doručení potřeba, dočasnou schránku pro manuální kontroly necitlivých případů, firemní schránku pro uchovávané nebo citlivé scénáře, SMTP catcher, když ovládáte nastavení odchozí pošty, a hostované API pro doručenou poštu pro end-to-end testy bez dozoru.

Pro manuální případy otevřete dočasnou schránku a začněte s registračním tokem, který příště nasadíte. Dočasná pošta má dostatek také spoustu praktických využití mimo QA.