„Az e-mail megérkezett” nem elegendő teszteredmény.
Egy regisztrációs üzenet eljuthat a beérkező levelekhez rossz címzett, lejárt hivatkozás, hibás mobil elrendezés, éles környezet hostneve, vagy olyan tárgysor miatt, amely más nyelven értelmetlen. A jó e-mail tesztelés az egész felhasználói utat követi, és elegendő bizonyítékot hagy hátra a hiba diagnosztizálásához.
Az ideiglenes postafiókok itt hasznosak, mivel minden futás egy tiszta címmel kezdődhet. A postafióknak eldobhatónak kell lennie; a teszteredménynek nem.
Építsünk egy kis, szándékos mátrixot
- új fiók ellenőrzése;
- jelszó visszaállítása;
- csapat- vagy munkaterület-meghívás;
- e-mail cím módosításának megerősítése;
- bejelentkezési hivatkozás vagy egyszeri kód;
- biztonsági riasztás érzékeny művelet után.
Minden folyamatnál teszteljük a sikeres útvonalat, egy lejárt vagy újrahasznált hitelesítő adatot, valamint egy címzettoldali hibát. Ez több valós hibát fed fel, mint ha tucatnyi azonos sikeres útvonalú üzenetet küldenénk.
Használjunk egy postafiókot szcenáriónként
Egy cím újrahasználata bizonytalanságot okoz. Egy régi visszaállítási üzenet összetéveszthető a legújabbal, és a párhuzamos tesztek egymás hivatkozásait fogyaszthatják.
Generáljunk egyedi címet minden tesztesethez vagy tesztfutáshoz. Rögzítsük a build szám, környezet, nyelv és szcenárió mellett. Ha egy teszt sikertelen, a cím a bizonyíték része lesz, és ellenőrizhető, mielőtt a tárolási idő lejár.
Ne használjunk valós ügyfélcímeket staging környezetben. Ez nemkívánatos üzeneteket eredményez, szennyezi az analitikát, és nehezíti az automatikus takarítást.
Ellenőrizzük a borítékot a tartalom előtt
Mielőtt bármit kattintanánk, ellenőrizzük:
- Az üzenet a teszthez létrehozott pontos címre érkezett.
- A feladó domainje a környezethez vártnak megfelelő.
- A tárgy azonosítja a műveletet anélkül, hogy érzékeny adatot felfedne.
- Csak a kívánt számú üzenet érkezett.
- Az időbélyeg későbbi, mint a kiváltó művelet.
Ezek az ellenőrzések a routing és duplikációs problémákat már a tartalomfeldolgozó elrejtése előtt felfedik.
Teszteljük a tartalmat úgy, ahogy a felhasználó látja
Nyissuk meg az üzenetet szűk és széles nézetben is. Ellenőrizzük, hogy az elsődleges művelet látható, a egyszerű szöveges alternatíva érthető, és a hosszú címek vagy URL-ek ne törjék meg a layoutot.
Kód-alapú folyamat esetén ellenőrizzük, hogy a legújabb kód egyszer működik, majd használat után hibát jelez. Hivatkozás-alapú folyamatnál erősítsük meg a hostot és a környezetet a megnyitás előtt. Egy staging üzenet, amely az éles környezetre mutat, kiadási akadály, még ha a hivatkozás technikailag működik is.
Ellenőrizzük a kevésbé csillogó részleteket is: a válaszcím viselkedése, a támogatási elérhetőség, a lejárati szöveg, a nyelv, valamint a üzenetben megjelenő fiók vagy munkaterület neve.
Negatív esetek, amelyek megérik a helyüket
Hasznos negatív tesztek közé tartozik:
- második kód kérése és annak megerősítése, hogy az első érvénytelenedik;
- lejárt hivatkozás megnyitása;
- ugyanazon hivatkozás kétszeri megnyitása;
- a fiók állapotának módosítása a üzenet felhasználása előtt;
- egy már taghoz tartozó cím meghívása;
- nem támogatott vagy hibás formátumú cím megadása;
- a kézbesítés késleltetése annyira, hogy átlépje a lejárati határt.
Ezek a tesztek feltárják a versenyhelyzeteket és a félrevezető hibaüzeneteket, amelyeket egy egyszerű postafiók-ellenőrzés sosem találna meg.
A termékhibák és a kézbesítési késés szétválasztása
Ha egy üzenet hiányzik, őrizzük meg az időbélyegeket a felhasználói művelet, az alkalmazás sorba állítása, a szolgáltató átadása és a postafiók érkezése esetén, ha ezek az információk elérhetők. Egy üres postafiók képernyőképe csak azt bizonyítja, hogy az üzenet abban a pillanatban nem volt látható.
Használjuk a diagnosztikai sorozatot a Az ellenőrző e-mail nem érkezik meg: a hibás lépés megtalálása cikkben, mielőtt egy homályos „e-mail hibás” problémát nyújtanánk be.
Mit automatizáljunk
Automatizáljuk a stabil szerződéseket:
- generáljunk egyedi címet;
- indítsuk el a termék műveletét;
- poll-oljuk korlátozott időtúllépéssel és visszalépéssel;
- egyeztessük a várt feladót és tárgyat;
- olvassuk el a legújabb egyező üzenetet;
- validáljuk a kódot vagy hivatkozást a termékkel;
- mentsük el a hasznos hibabizonyítékot;
- takarítsuk el.
A vizuális ellenőrzést, a szöveg minőségét és a szokatlan kliens viselkedést tartsuk fókuszált manuális lépésben. Az automatizálás jó a ismétlésben, nem pedig az ízlésben.
Megbízható ideiglenes postafiók API automatizálás lefedi az API oldalt, beleértve a poll-olást és a takarítást.
Hasznos hibajelentés
Egy olyan jelentés, amelyre a fejlesztők reagálni tudnak, tartalmazza a szcenáriót, környezetet, címet, kiváltó időt, a várt feladót, a megfigyelt üzeneteket, az utolsó lekérdezés időpontját, a válasz állapotát, valamint egy képernyőképet vagy szanitizált tartalomkivonatot. Soha ne csatoljunk élő titkokat vagy újrahasználható ellenőrző hivatkozásokat egy nyilvános problémához.
A cél nem az, hogy bizonyítsuk az e-mail megbízhatatlanságát. Hanem az, hogy azonosítsuk, melyik szerződés hibázott, és hagyjunk egy reprodukálható utat a javításhoz.