Kysy keneltä tahansa QA-insinööriltä, missä ilkeimmät bugit piileskelevät, ja he kertovat sinulle saman asian: ei yhden käyttäjän onnellisella polulla, vaan tilassa käyttäjien välissä. Kaksi henkilöä rekisteröityy samalla hetkellä. Kutsusähköposti menee väärälle henkilölle. Ylläpitäjä ja pelkän lukuoikeuden jäsen lataavat saman sivun, ja toinen heistä näkee jotain, mitä ei pitäisi. Mikään tästä ei toistu, kun testaat yksin omalla sähköpostiosoitteellasi, koska tietokannassa olet aina vain yksi käyttäjä.

Aidot tuotteet ovat luonteeltaan monen käyttäjän — tiimit, työtilat, roolit, kutsut, suositukset, vuokralaiset. Testataksesi näitä prosesseja rehellisesti tarvitset useita erillisiä, tavoitettavia postilaatikoita samanaikaisesti. Tässä kertakäyttöisestä postilaatikosta tulee hiljaa yksi testaajan työkalupakin hyödyllisimmistä työkaluista, ja se on käyttötapaus, jolla ei ole mitään tekemistä roskapostilta piiloutumisen kanssa.

Miksi yksi aito postilaatikko (tai jaettu QA-Gmail) ei riitä

Oman osoitteesi ongelma on yksinkertainen: se on jo olemassa järjestelmässä. Et voi simuloida "aivan uutta käyttäjää, jota ei ole koskaan ennen nähty", kun tietuesi on jo tietokannassa, etkä varmasti voi olla kolme eri uutta käyttäjää kerralla. Tiimit turvautuvat usein jaettuun QA-Gmail-tiliin ja nojaavat plus-osoitteistukseen — [email protected], [email protected] ja niin edelleen. Se toimii, kunnes ei toimi: monet sovellukset poistavat tai normalisoivat +-tunnisteen, jotkin hylkäävät sen suoralta kädeltä, ja silloinkin kun se hyväksytään, jokainen viesti päätyy silti yhteen postilaatikkoon, joka sinun täytyy sitten selvittää saadaksesi selville, mikä "käyttäjä" vastaanotti minkäkin.

Aidosti monen käyttäjän testaukseen haluat postilaatikoita, jotka ovat oikeasti erillisiä — erilliset osoitteet, erilliset postilaatikot, ei jaettua tilaa. Juuri tämän saat avaamalla muutaman välilehden.

Mihin kertakäyttöiset postilaatikot sopivat QA:ssa

Jokainen temp mail -välilehti on täysin itsenäinen postilaatikko omalla ainutlaatuisella osoitteellaan. Avaa kolme välilehteä, ja sinulla on kolme aitoa käyttäjää, joille voit lähettää ja joilta voit vastaanottaa — ei tilin luomista, ei jaettua postilaatikkoa siivottavaksi jälkikäteen, ja koska jokainen osoite on tuoreesti luotu, eilisen testiajon jäljiltä ei jää mitään tilaa sotkemaan tämän päivän tuloksia. Kun olet valmis, kaikki poistuu automaattisesti tunnin kuluttua, joten et rakenna testitilien hautausmaata henkilökohtaiseen sähköpostiisi liitettynä.

Monen käyttäjän skenaariot, joita todella kannattaa testata

Tässä ovat prosessit, joissa useiden aktiivisten postilaatikoiden pitäminen rinnakkain kannattaa — ne, jotka hiljaa rikkoutuvat tuotannossa, koska kukaan ei voinut helposti toistaa niitä ennen julkaisua:

• Tiimi- ja työtilakutsut: Käyttäjä A luo työtilan ja kutsuu B:n ja C:n. Jokaisen kutsun on tavoitettava oikea osoite toimivalla, turvallisesti luodulla linkillä, ja sen hyväksymisen on pudotettava kukin henkilö oikeaan työtilaan oikealla roolilla. Seuraa kaikkia kolmea postilaatikkoa yhtä aikaa, ja huomaat väärin reititetyn kutsun välittömästi.
• Roolit ja käyttöoikeudet: Rekisteröi omistaja, ylläpitäjä ja pelkän lukuoikeuden jäsen kolmena erillisenä käyttäjänä. Vahvista sitten, että jokainen näkee — ja ei voi nähdä — täsmälleen sen, minkä hänen roolinsa sallii. Käyttöoikeusbugit ovat näkymättömiä, kunnes olet oikeasti kirjautuneena alemman oikeuden käyttäjänä, mieluiten samaan aikaan kuin ylemmän. OWASP Authorization Cheat Sheet on hyvä tarkistuslista siitä, mitä tässä kannattaa tutkia.
• Kaksoistilien käsittely: Rekisteröi kaksi tiliä eri osoitteilla, yritä sitten käyttää toista uudelleen. Havaitseeko sovellus kaksoiskappaleen odottamallasi tavalla? Entä sama osoite eri kirjainkoolla tai ylimääräisellä lopussa olevalla pisteellä? Tuoreet osoitteet tekevät näistä reunatapauksista triviaaleja asettaa.
• Suositus- ja kutsupalkintoprosessit: Suosittelija saa yleensä hyvityksen vasta, kun suositeltu rekisteröityy ja vahvistaa. Tarvitset kaksi aitoa postilaatikkoa nähdäksesi molempien puolten laukeavan — kutsun lähtevän ja palkinnon saapuvan (tai oikein olevan saapumatta), kun toinen käyttäjä suorittaa prosessin loppuun.
• Monivuokralaisten eristäminen: Luo tilit kahteen erilliseen organisaatioon ja vahvista, että yhden vuokralaisen data ei koskaan vuoda toisen näytöille, ilmoituksiin tai sähköposteihin — juuri sellainen vika, jonka NIST:n pilvimonivuokralaisuutta koskeva ohjeistus nimenomaisesti nostaa esiin. Harhautunut osoite väärässä postilaatikossa on usein ensimmäinen näkyvä merkki datan eristysbugista.
• Samanaikaiset rekisteröitymiset: Rekisteröi useita käyttäjiä saman sekunnin sisällä ravistellaksesi esiin kilpailutilanteita tokenien luomisessa, ainutlaatuisuusrajoitteiden törmäyksiä ja jonoviiveitä, joiden vuoksi jotkin vahvistussähköpostit saapuvat paljon myöhemmin kuin toiset.
• Paikka- ja tilausrajat: Täytä tilaus paikkakattoonsa asti erillisillä käyttäjillä, yritä sitten lisätä vielä yksi. Rajan tulisi pitää — ja virheen, jonka ylimääräinen käyttäjä kohtaa, tulisi olla selkeä, ei 500.
• Ilmoitusten leviäminen: Laukaise toiminto yhdellä tilillä ja vahvista, että oikeat tiimikaverit — ja vain he — vastaanottavat ilmoitussähköpostin. On helppoa lähettää vahingossa sähköposti kaikille tai ei kenellekään.

Työnkulku, joka pitää sen hallittavana

Käytännöllinen niksi on kohdella jokaista välilehteä nimettynä hahmona testissäsi. Avaa yksi välilehti käyttäjää kohti ja päätä etukäteen, mikä on mikä — Omistaja, Ylläpitäjä, Jäsen — kopioi sitten kukin osoite omaan rekisteröitymiseensä. Järjestä välilehdet niin, että näet ne yhdellä silmäyksellä. Koska toimitus on käytännössä välitön, näet kutsun saapuvan samalla hetkellä kun lähetät sen, mikä tekee syyn ja seurauksen ilmeiseksi tavalla, jota jaetun postilaatikon kysely ei koskaan tee.

Merkitse testivaiheittesi viereen muistiin, mikä satunnainen osoite vastaa mitäkin roolia — osoitteet ovat luotuja, eivät valittuja, joten nopea muistiinpano säästää myöhemmin sekaannuksilta. Ja palkinto: sillä hetkellä, kun sähköposti ilmestyy väärään välilehteen, olet napannut reititys- tai eristysbugin siihen paikkaan, kauan ennen kuin siitä tulee tukipyyntö.

Mitä tarkistaa, kun posti saapuu

Sähköpostin vastaanottaminen on vasta puolet. Kun viesti saapuu, käytä pari sekuntia sen todelliseen varmistamiseen:

• Oikea vastaanottaja: Menikö kutsu kutsuttuun osoitteeseen — eikä minnekään muualle?
• Oikea linkki: Osoittaako hyväksymis- tai vahvistus-URL oikeaan ympäristöön ja kantaako se oikean työtila- ja roolikontekstin, ei kovakoodattua tuotantolinkkiä?
• Oikea lopputila: Onko uusi käyttäjä hyväksymisen jälkeen oikeassa organisaatiossa täsmälleen niillä käyttöoikeuksilla, jotka hänen roolillaan tulisi olla?
• Renderöinti: Näyttääkö sähköposti oikealta aidossa postilaatikossa — painikkeet klikattavissa, vastaanottajan nimi täytettynä, ei jäljelle jäänyttä "Hei {{firstName}}" -paikkamerkkiä?
• Eristys: Viittaako yhden käyttäjän sähköposti koskaan vahingossa toisen käyttäjän dataan? Se on hälytysmerkki, jota kannattaa jäljittää.
• Ajoitus: Kaiken tulisi saapua parissa sekunnissa. Johdonmukainen viive viittaa jono- tai DNS-ongelmaan, jonka aidot käyttäjäsi myös tuntisivat.

Puhdas testidata, ilmaiseksi

Yksi aliarvostettu etu: jokainen kertakäyttöinen osoite alkaa tyhjänä ja katoaa tunnin kuluttua, joten jokainen ajo alkaa tunnetusti puhtaasta tilasta. Testi, joka alkaa "taatusti tyhjä postilaatikko, aivan uusi käyttäjä" -tilasta, on testi, johon voit oikeasti luottaa ja jonka voit ajaa uudelleen miettimättä, vääristävätkö viime viikon jäänteet tulosta. Toistettavuus on puolet hyvästä QA:sta, ja saat sen tässä tekemättä minkäänlaista siivousta.

Paras tutkivaan ja julkaisua edeltävään regressiotestaukseen

Tämä lähestymistapa loistaa todella tutkivan testauksen ja julkaisua edeltävän manuaalisen regressiokierroksen aikana. Parissa minuutissa voit pystyttää realistisen pienen käyttäjäjoukon — omistajan, pari jäsentä, ulkopuolisen kutsutun — ja käydä tuotteen läpi niin kuin oikea tiimi tekisi, ja katsoa sähköpostien laukeavan matkan varrella. Se on lähimpänä sitä, että "käyttäisit sovellusta viitenä eri henkilönä kerralla" ilman viiden aidon postilaatikon perustamista. Jos testaat myös yhden käyttäjän osia, oppaamme sähköpostin vahvistuksen testaamisesta ja salasanan nollausprosesseista sopivat luonnollisesti yhteen tämän kanssa.

Missä kannattaa olla rehellinen rajoituksista

Muutamasta asiasta kannattaa olla suora, koska muunlaisen esittäminen vain tuhlaa aikaasi. Jotkin sovellukset estävät tunnetut kertakäyttöiset sähköpostidomeenit rekisteröitymisen yhteydessä — jos rekisteröitymislomakkeesi hylkää osoitteen, se on sovelluksen oma käytäntö, ja niitä tiettyjä testejä varten saatat tarvita sen sijaan sallituille listatun sisäisen domeenin. Tämä on myös manuaalinen, tutkiva työnkulku: ohjaat selainta, et kutsu API:a, joten se täydentää automatisoituja päästä päähän -sähköpostitestejä CI:ssä sen sijaan, että korvaisi ne. Ja ennen kuin julkaiset, tee viimeinen kierros aidolla postilaatikolla kuten Gmailillä tai Outlookilla — toimitettavuuden erikoisuudet ja roskapostikansion käyttäytyminen paljastuvat vain aitoja palveluntarjoajia vastaan.

Lyhyt versio

Yhden postilaatikon testaus löytää yhden käyttäjän bugit. Ne, jotka todella pääsevät tuotantoon, elävät käyttäjien välisissä aukoissa — kutsut, roolit, vuokralaiset, rajat ja kilpailutilanteet. Kertakäyttöiset postilaatikot antavat yhden testaajan näytellä kokonaista tiimiä kerralla, puhtaalla tilalla joka ajolla, suunnilleen siinä ajassa, joka kuluu muutaman välilehden avaamiseen. Siirry osoitteeseen temp-email.ai, avaa yksi välilehti käyttäjää kohti, ja aloita niiden skenaarioiden testaaminen, joilla todella on merkitystä.