Olen julkaissut enemmän rekisteröitymisvirtoja kuin osaan laskea. Ja joka ikinen kerta sähköpostin vahvistuksen testausvaihe on sama tarina: postilaatikkoni täyttyy testiviesteistä, alan menettää käsityksen siitä mikä testi oli mikäkin, ja jossain neljännenkymmenennen testirekisteröinnin tienoilla alan jättää sähköpostit kokonaan huomiotta. Sanon itselleni, että siivoan ne myöhemmin. En siivoa. Kuusi kuukautta julkaisun jälkeen postilaatikossani on edelleen 200 testivahvistussähköpostia, jotka eivät tee mitään.

Se on aidosti huono tapa — ei vain siisteyden vuoksi, vaan itse testauksen laadun vuoksi. Kun postilaatikkosi on täynnä aiempia testisähköposteja, on paljon vaikeampaa varmistaa, että tietty testi juuri laukaisi tietyn lähetyksen. Alat tehdä oletuksia sen sijaan, että todella tarkistaisit. Jätät hienovaraiset virheet huomiotta. Ja koko asia on täysin tarpeeton, koska on paljon parempi lähestymistapa.

Tämä artikkeli käsittelee tilapäisen sähköpostin käyttöä keskeisenä osana kehitystyönkulkuasi rakentaessasi ja testatessasi sähköpostin vahvistusta. Se tekee prosessista nopeamman, siistimmän, perusteellisemman ja rehellisesti sanottuna paljon miellyttävämmän.

Mitä sähköpostin vahvistus oikeastaan pitää sisällään

Ennen kuin puhumme testauksesta, kannattaa olla tarkka siitä, mitä oikeastaan testaamme. Sähköpostin vahvistus ei ole vain »lähetä linkki». Se on monivaiheinen prosessi, jossa on useita itsenäisesti testattavia komponentteja, ja jokainen niistä voi epäonnistua eri ja joskus hienovaraisilla tavoilla.

Vaihe yksi: kryptografisesti turvallisen tunnisteen luominen. OWASP Authentication Cheat Sheet on tästä selkeä: vahvistustunnisteet on luotava kryptografisesti turvallisella satunnaislukugeneraattorilla, niiden on oltava vähintään 32 tavua pitkiä, ja ne on tallennettava tavalla, joka mahdollistaa palvelinpuolen validoinnin olematta käännettävissä. Ei peräkkäinen kokonaisluku. Ei ennustettava tiiviste käyttäjätunnuksesta. Kunnollinen satunnainen tunniste.

Vaihe kaksi: tunnisteen tallentaminen asianmukaisilla metatiedoilla — kenelle käyttäjälle se kuuluu, milloin se luotiin, milloin se vanhenee ja onko sitä jo käytetty. Vaihe kolme: sähköpostin rakentaminen. Tämä tarkoittaa aiheriviä, lähettäjän nimeä, runkoa, vahvistus-URL-osoitetta ja sen varmistamista, että kyseinen URL osoittaa oikeaan ympäristöön (ei tuotantoon kehityspalvelimeltasi). Vaihe neljä: sähköpostin toimittaminen SMTP:n kautta. RFC 5321 määrittelee Simple Mail Transfer Protocol -määrittelyn — jo perusteiden ymmärtäminen siitä, miten SMTP toimii, auttaa sinua diagnosoimaan toimitusongelmia niiden ilmetessä.

Vaihe viisi: käyttäjä napsauttaa linkkiä. Palvelimesi validoi tunnisteen: onko se olemassa? Onko se vanhentunut? Onko sitä käytetty aiemmin? Jos kaikki tarkistukset läpäistään, tili merkitään vahvistetuksi ja tunniste mitätöidään. Jos jokin tarkistus epäonnistuu, käyttäjä saa selkeän virheilmoituksen. Jokainen näistä vaiheista on testitapaus. Jokainen voi mennä vikaan eri tavalla. Perusteellinen testaustyönkulku kattaa ne kaikki.

Miksi oikealla sähköpostilla testaaminen on huono idea

Oikean sähköpostiosoitteesi käyttämisessä kehitystestaukseen on useita konkreettisia ongelmia, jotka kertyvät projektin kuluessa. Ilmeisin on sotku — sadan testirekisteröinnin jälkeen postilaatikkosi on täynnä vahvistussähköposteja, jotka ovat nyt hyödyttömiä. Tietyn testituloksen löytäminen siitä hälystä on aidosti vaikeaa. Saatat alkaa suodattaa nämä sähköpostit automaattisesti pois, mikä tarkoittaa, että lakkaat todella lukemasta niitä, mikä tarkoittaa, että lakkaat huomaamasta renderöintivirheitä ja sisältövirheitä malleissasi.

On myös perustavanlaatuisempi ongelma: et voi simuloida »uutta käyttäjää, jota ei ole koskaan ennen nähty» oikealla sähköpostiosoitteellasi. Osoitteesi on jo olemassa tietokannassasi. Testataksesi tuoretta rekisteröitymistä sinun täytyy poistaa tilisi ja rekisteröityä uudelleen — mikä on vaivalloista ja tarkoittaa, ettet voi säilyttää mitään aiempaa testitilaa. Tilapäisellä osoitteella jokainen testi on aidosti tuore käyttäjä, jolla on aidosti tuore postilaatikko.

Lisäksi jotkin sähköpostipalveluntarjoajat alkavat suodattaa toistuvia samankaltaisia viestejä roskapostina, kun ne tulevat samasta lähetysverkkotunnuksesta lyhyessä ajassa. Testilähetyksesi saattavat lakata saapumasta postilaatikkoosi lainkaan, mikä saa sinut luulemaan, että toimitusputkesi on rikki, vaikka se ei ole. Etkä yksinkertaisesti voi testata samanaikaisia rekisteröitymisiä — jos sinun täytyy varmistaa, mitä tapahtuu, kun kolme käyttäjää rekisteröityy samanaikaisesti, et voi tehdä sitä yhdellä oikealla sähköpostiosoitteella.

Tilapäisen sähköpostin ratkaisu — vaihe vaiheelta

Tässä on tarkalleen, miten käytän temp-email.ai:ta kehitystyönkulussani. Avaa tilapäinen sähköposti selaimen välilehdellä kehitysympäristösi rinnalla. Ainutlaatuinen osoite odottaa sinua välittömästi — ei asetuksia, ei tilin luomista. Kopioi se yhdellä napsautuksella.

Vaihda sovellukseesi. Mene rekisteröitymis- tai kirjautumissivulle. Liitä tilapäinen osoite sähköpostikenttään ja täytä loput lomakkeesta. Lähetä. Vaihda takaisin temp-email.ai-välilehteen. Jos sähköpostin toimituksesi on asetettu oikein, vahvistussähköposti saapuu 2–5 sekunnin sisällä. Näet aiherivin, lähettäjän nimen ja koko sähköpostin rungon renderöitynä juuri sellaisena kuin se näkyisi missä tahansa oikeassa sähköpostiohjelmassa.

Napsauta vahvistuslinkkiä suoraan tilapäisestä postilaatikosta. Sovelluksesi pitäisi käsitellä se oikein — ohjata oikealle sivulle, näyttää onnistumistila ja merkitä tili vahvistetuksi. Olet juuri suorittanut täyden päästä päähän -testin vahvistusvirrastasi. Avaa nyt toinen välilehti ja tee se uudelleen tuoreella osoitteella testataksesi samanaikaisen rekisteröitymisen. Koko prosessi »täytyy testata» -tilasta »testi valmis» -tilaan kestää noin kaksi minuuttia.

Mitä testata vahvistusvirrassasi

Tässä on kattava tarkistuslista, jonka käyn läpi testatessani sähköpostin vahvistustoteutusta:

• Perustoimitus: Saapuuko sähköposti? Testaa tätä useilla lähetysskenaarioilla — mitä tapahtuu, kun rekisteröidyt tuoreessa paikallisympäristössä vs. testiympäristössä vs. tuotannossa? Toimitusongelmat ovat usein ympäristökohtaisia.
• Linkin oikeellisuus: Osoittaako sähköpostin vahvistus-URL oikeaan ympäristöön? On nolostuttavan helppoa kovakoodata tuotanto-URL malliin, jota sitten käytetään kehityksessä. Linkki pitäisi rakentaa dynaamisesti perus-URL-määrityksestäsi.
• Tunnisteen turvallisuus: Onko tunniste vähintään 32 merkkiä ja aidosti satunnainen? Tarkista tunniste URL-osoitteessa — sen pitäisi näyttää satunnaiselta kirjain- ja numerojonolta, ei ennustettavalta kaavalta. Katso OWASP Authentication Cheat Sheet saadaksesi tarkkoja ohjeita tunnisteen luomiseen.
• Tunnisteen vanheneminen: Mitä tapahtuu, kun annat vahvistuslinkin olla pidempään kuin vanhenemisikkunasi ja sitten napsautat sitä? Sovelluksesi pitäisi käsitellä tämä sujuvasti — selkeä viesti, joka kertoo käyttäjälle linkin vanhentuneen, ja kehote pyytää uutta. Ei geneeristä 500-virhettä.
• Kertakäytön valvonta: Voiko samaa vahvistuslinkkiä käyttää kahdesti? Kun olet vahvistanut kerran, linkin napsauttamisen uudelleen ei pitäisi onnistua. Sen pitäisi kertoa käyttäjälle, että tili on jo vahvistettu tai että linkki on virheellinen. Testaa tämä nimenomaisesti.
• Uudelleenrekisteröityminen ennen vahvistusta: Mitä tapahtuu, jos käyttäjä rekisteröityy, ei vahvista sähköpostiaan ja yrittää sitten rekisteröityä uudelleen samalla osoitteella? Käsitteleekö sovelluksesi tämän oikein — joko lähettää vahvistuksen uudelleen tai kehottaa tarkistamaan postilaatikon?
• Uudelleenlähetystoiminto: Toimiiko »lähetä vahvistussähköposti uudelleen» -painike? Mitätöikö sen napsauttaminen edellisen tunnisteen ja lähettää tuoreen? Testaa napsauttamalla sitä useita kertoja nopeasti — mitä tapahtuu, jos joku napsauttaa uudelleenlähetystä kymmenen kertaa?
• HTML-renderöinti: Renderöityykö sähköpostimallisi oikein oikeassa postilaatikossa? Tarkista temp-email.ai-katselimessa: ovatko painikkeet todella napsautettavissa? Latautuvatko kuvat? Onko asettelu ehjä sekä työpöytä- että mobiiliesikatselussa? Ylittääkö teksti jossain reunat?
• Aiherivi ja lähettäjän nimi: Onko aiherivi selkeä, ammattimainen eikä altis roskapostilaukaisijoille? Onko lähettäjän nimi brändinimesi eikä geneerinen palveluntarjoajan nimi? Näillä on merkitystä toimitettavuudelle ja käyttäjän luottamukselle.
• Personointi: Täyttyikö käyttäjän nimi tai käyttäjätunnus oikein siihen, missä sen pitäisi näkyä sähköpostin rungossa? Tämä on yleinen mallivirhe — muuttujan korvaus epäonnistuu hiljaa ja päädyt lähettämään »Hei {{firstName}}» eikä »Hei Sarah».

Testaaminen eri skenaarioissa

Vakiorekisteröityminen ei ole ainoa virta, joka lähettää sähköpostin vahvistustyyppisiä viestejä. Jos sovelluksesi tukee sosiaalista kirjautumista — »Rekisteröidy Googlella» tai OAuth vastaavien palveluntarjoajien kautta — useimmat toteutukset lähettävät silti tervetulosähköpostin tai tilin luontivahvistuksen. Testaa myös se virta. Avaa tilapäinen postilaatikko, käytä sitä OAuth-testisi liitettynä sähköpostina ja varmista, että tervetulosähköposti saapuu ja näyttää oikealta.

Salasanan nollausvirrat ovat rakenteellisesti lähes identtisiä sähköpostin vahvistuksen kanssa: luo turvallinen tunniste, lähetä linkki sähköpostilla, validoi napsautuksen yhteydessä, mitätöi käytön jälkeen. Jokainen yllä olevan testaustarkistuslistan kohta pätee yhtä lailla salasanan nollaukseen. Samoin sähköpostiosoitteen muutosvahvistus — kun käyttäjä päivittää sähköpostinsa asetuksissa, sinun täytyy vahvistaa uusi osoite ennen vaihdon tekemistä. Se on toinen täydellinen sähköpostivirta testattavaksi itsenäisesti.

Kutsusähköpostit — joissa käyttäjä kutsuu kollegan liittymään — lisäävät toisen ulottuvuuden: kutsutun postilaatikon. Tilapäisillä sähköpostiosoitteilla voit testata kutsuvirran molemmat puolet samassa selainistunnossa. Lähetä päätestitililtäsi, vastaanota tilapäiseen osoitteeseen, hyväksy ja varmista hyväksynnän jälkeinen tila. Siistiä, täydellistä ja nopeaa.

Useat samanaikaiset käyttäjät

Tämä on yksi tilapäisten sähköpostiosoitteiden suurimmista eduista kehitystestauksessa, ja se on jotain, mikä on yksinkertaisesti mahdotonta yhdellä oikealla sähköpostitilillä. Jokainen temp-email.ai:n selainvälilehti on täysin itsenäinen postilaatikko. Voit avata viisi välilehteä samanaikaisesti, kukin eri osoitteella, rekisteröidä viisi tiliä sovelluksessasi samaan aikaan ja katsoa viiden itsenäisen vahvistussähköpostin saapuvan reaaliajassa viiteen erilliseen postilaatikkoon.

Tämänkaltainen samanaikainen testaus nappaa kokonaisen luokan virheitä, joita peräkkäinen yhden käyttäjän testaus ei koskaan nappaa: kilpailutilanteita tunnisteen luonnissa, tietokannan lukkiutumisia ainutlaatuisuusrajoitteiden tarkistuksissa, jonon käsittelyviiveitä, jotka aiheuttavat joidenkin vahvistussähköpostien saapumisen paljon muita myöhemmin, ja odottamattomia vuorovaikutuksia samanaikaisten istuntojen välillä. Jos rakennat tuotetta, joka odottaa enemmän kuin kourallisen käyttäjiä, samanaikaisen rekisteröitymisen testaaminen ei ole valinnaista — se on välttämätöntä. Tilapäiset osoitteet tekevät siitä naurettavan helppoa.

Vahvistuksen ulkopuolella — muut testattavat tapahtumasähköpostit

Kun sinulla on tilapäisen sähköpostin työnkulku käynnissä, sovella sitä jokaiseen tapahtumasähköpostiin, jonka sovelluksesi lähettää. Jokainen näistä ansaitsee oman erillisen testikierroksensa:

• Salasanan nollaussähköpostit: Samat tunnisteen turvallisuus- ja vanhenemisnäkökohdat kuin vahvistuksessa. Testaa vanhentunut linkki- ja jo käytetty -skenaariot nimenomaisesti.
• Kutsusähköpostit: Kutsuttu vastaanottaa tämän, ei olemassa oleva käyttäjä — täydellinen käyttötapaus tuoreelle tilapäiselle postilaatikolle.
• Tilausvahvistus- ja kuittisähköpostit: Tarkista, että kaikki tuotetiedot, hinnat ja linkit ovat oikein. Rikkinäinen tilausvahvistus on asiakaspalvelun painajainen.
• Toimintailmoitussähköpostit: Koostetiivistelmät, maininta-ilmoitukset, toimintasyötteet. Testaa, että ne lähetetään vain, kun relevantti toiminta todella tapahtui.
• Tilauksen peruutuksen vahvistussähköpostit: Kun käyttäjä peruuttaa markkinointitilauksen, saako hän vahvistuksen? Onko yhden napsautuksen peruutusotsikko (vaadittu massalähettäjille) läsnä?
• Tilin poiston vahvistus: Jos sovelluksesi lähettää lopullisen vahvistuksen, kun käyttäjä poistaa tilinsä, varmista, että tämä toimii ja että voit todella lukea sähköpostin tilapäisessä postilaatikossa ennen kuin tili on poissa.

Mitä etsiä testisähköposteistasi

Kun vastaanotat testisähköpostin tilapäiseen postilaatikkoosi, älä vain napsauta linkkiä ja jatka eteenpäin. Käytä viisitoista sekuntia todella katsoaksesi sähköpostin kunnolla. Tarkista otsakkeet, jos tilapäinen postilaatikkosi paljastaa ne — läpäisikö SPF ja DKIM? Sillä on merkitystä toimitettavuudelle todellisille vastaanottajille. Jos lähetysverkkotunnustasi ei ole määritetty oikein DKIM:iä varten, sähköpostisi saattavat päätyä roskapostiin oikeilla käyttäjillä, vaikka ne toimisivat hyvin testiympäristöissä.

Katso HTML-renderöintiä. Malli voi näyttää täydelliseltä paikallisessa sähköpostin esikatselutyökalussasi ja sitten hajota oikeassa postilaatikossa, koska eri sähköpostiohjelmat käsittelevät CSS:ää hyvin eri tavoin. Sen katsominen oikeassa postilaatikossa — vaikka tilapäisessä — nappaa ongelmat, jotka esikatselutyökalut jättävät huomiotta. Tarkista painikkeet, tarkista kuvien lataus, tarkista, ettei mitään tekstiä leikkaudu tai vuoda yli säiliöstään. Jos voit katsoa myös mobiilirenderöintiä, tee niin — suhteettoman suuri osuus sähköposteista avataan mobiililaitteella.

Tarkista toimitusaika. Oikein määritetylle tapahtumasähköpostin asetukselle toimituksen tilapäiseen postilaatikkoon ei pitäisi kestää enempää kuin 2–5 sekuntia siitä hetkestä, kun laukaiset lähetyksen. Johdonmukaiset sitä pidemmät viiveet — sanotaanko 20–30 sekuntia — viittaavat jonon käsittelyongelmaan tai DNS-selvitysviiveeseen lähetysasetuksissasi, jota kannattaa tutkia ennen kuin oikeat käyttäjäsi kokevat sen.

Tästä tavan tekeminen

Työnkulun muutos on aidosti pieni. Sen sijaan, että kirjoittaisit oikean sähköpostiosoitteesi testirekisteröintilomakkeeseen, käytät viisi sekuntia avataksesi tilapäisen sähköpostin uudessa välilehdessä ja kopioidaksesi osoitteen sieltä. Se on koko muutos. Mutta sen alavirran vaikutus testauksen laatuun on merkittävä.

Testaat perusteellisemmin, koska tarkistaminen on kitkatonta. Nappaat enemmän renderöintivirheitä, koska katsot oikean postilaatikon renderöintiä joka kerta. Voit testata samanaikaisia skenaarioita, jotka olivat aiemmin epäkäytännöllisiä. Oikea postilaatikkosi pysyy puhtaana. Ja rakennat tavan kohdella sähköpostia ensiluokkaisena testauspintana pikemminkin kuin jälkiajatuksena — mikä on oikea mielenmalli sellaisten tuotteiden rakentamiseen, joihin ihmiset todella luottavat.