„„E‑mail dorazil“ není dostatečný výsledek testu.“
Zpráva o registraci může dorazit do schránky s nesprávným příjemcem, s prošlým odkazem, s rozbitým mobilním rozložením, s produkčním hostname nebo s předmětem, který nedává smysl v jiném jazyce. Dobré testování e‑mailů sleduje celý uživatelský tok a ponechává dostatek důkazů pro diagnostiku selhání.
Dočasné schránky jsou zde užitečné, protože každé spuštění může začít s čistou adresou. Schránka by měla být jednorázová; výsledek testu ne.
Vytvořte malou, úmyslnou mřížku
Začněte s toky, které mohou uživatele zablokovat:
- ověření nového účtu;
- reset hesla;
- pozvání do týmu nebo pracovního prostoru;
- potvrzení změny e‑mailu;
- odkaz pro přihlášení nebo jednorázový kód;
- bezpečnostní upozornění po citlivé akci.
Pro každý tok otestujte šťastnou cestu, jeden prošlý nebo znovu použitý credential a jednu chybu na straně příjemce. To zachytí více reálných vad než posílání desítek identických šťastných zpráv.
Používejte jednu schránku na scénář
Opakované používání jedné adresy vytváří nejasnosti. Stará zpráva o resetu může být zaměněna za nejnovější a paralelní testy si mohou navzájem spotřebovávat odkazy.
Vygenerujte jedinečnou adresu pro každý testovací případ nebo spuštění. Zaznamenejte ji spolu s číslem buildu, prostředím, locale a scénářem. Pokud test selže, adresa se stane součástí důkazů a může být zkontrolována před vypršením retenční doby.
Neužívejte skutečné zákaznické adresy ve stagingu. To riskuje nechtěné zprávy, znečišťuje analytiku a ztěžuje automatické čištění.
Ověřte obálku před tělem zprávy
Než kliknete na cokoliv, ověřte:
- Zpráva byla odeslána na přesně tu adresu vytvořenou pro tento test.
- Doména odesílatele je ta očekávaná pro dané prostředí.
- Předmět identifikuje akci, aniž by odhaloval citlivá data.
- Dorazil jen očekávaný počet zpráv.
- Časové razítko je pozdější než akce, která ji spustila.
Tyto kontroly zachytí problémy s routováním a duplikací dříve, než je je skryje parser těla zprávy.
Testujte obsah tak, jak jej uživatel vidí
Otevřete zprávu jak v úzkém, tak v širokém viewportu. Zkontrolujte, že hlavní akce je viditelná, že fallback v prostém textu je srozumitelný a že dlouhé adresy nebo URL nerozbíjejí rozložení.
U toku založeného na kódu ověřte, že nejnovější kód funguje jednou a po použití selže. U toku založeného na odkazu potvrďte hostitele a prostředí před jeho otevřením. Zpráva ve stagingu, která ukazuje na produkci, je blokátor vydání, i když odkaz technicky funguje.
Zkontrolujte také méně okouzlující detaily: chování reply‑to, kontaktní podporu, formulaci expirace, locale a název účtu nebo pracovního prostoru uvedený ve zprávě.
Negativní případy, které mají smysl
Užitečné negativní testy zahrnují:
- požádání o druhý kód a potvrzení, že první byl zneplatněn;
- otevření prošlého odkazu;
- otevření stejného odkazu dvakrát;
- změna stavu účtu před použitím zprávy;
- pozvání adresy, která již patří členu;
- zadání nepodporované nebo špatně formátované adresy;
- zpoždění doručení natolik, že překročí hranici expirace.
Tyto testy odhalují závodní podmínky a zavádějící chybové zprávy, které jednoduchá kontrola schránky nikdy neodhalí.
Oddělte selhání produktu od zpoždění doručení
Když zpráva chybí, uchovejte časová razítka pro uživatelskou akci, zařazení do fronty aplikací, předání poskytovateli a příjem do schránky, pokud jsou tyto signály dostupné. Screenshot prázdné schránky dokazuje jen, že zpráva v daném okamžiku nebyla viditelná.
Použijte diagnostickou sekvenci v Ověřovací e-mail nedorazil: Najděte nefunkční krok před podáním vágního „e‑mail rozbitý“ issue.
Co automatizovat
Automatizujte stabilní kontrakty:
- vygenerujte jedinečnou adresu;
- spustěte produktovou akci;
- pollujte s omezeným timeoutem a backoffem;
- porovnejte očekávaného odesílatele a předmět;
- přečtěte nejnovější odpovídající zprávu;
- ověřte kód nebo odkaz vůči produktu;
- uložte užitečné důkazy o selhání;
- vyčistěte.
Vizuelní revizi, kvalitu textu a neobvyklé chování klienta ponechte na zaměřeném manuálním průchodu. Automatizace je dobrá pro opakování, ne pro vkus.
Spolehlivá automatizace API dočasných schránek pokrývá API část, včetně pollování a úklidu.
Užitečná zpráva o selhání
Zpráva, na kterou mohou vývojáři reagovat, obsahuje scénář, prostředí, adresu, čas spuštění, očekávaného odesílatele, pozorované zprávy, čas posledního pollování, stav odpovědi a screenshot nebo sanitovaný výpis těla. Nikdy nepřikládejte živé tajné klíče ani znovupoužitelné ověřovací odkazy k veřejnému issue.
Cílem není dokázat, že e‑mail je nespolehlivý. Je to identifikovat, který kontrakt selhal, a nechat reprodukovatelnou cestu k opravě.