"El correu electrònic ha arribat" no és un resultat de prova suficient.
Un missatge de registre pot arribar a la safata d'entrada amb el destinatari incorrecte, un enllaç caducat, un disseny mòbil trencat, un nom d'amfitrió de producció o una línia d'assumpte que no té sentit en una altra llengua. Un bon test de correu electrònic segueix tot el viatge de l'usuari i deixa prou evidència per diagnosticar una fallada.
Les bústies temporals són útils aquí perquè cada execució pot començar amb una adreça neta. La bústia ha de ser descartable; el resultat del test no ho ha d'estar.
Construeix una matriu petita i deliberada
Comença amb els fluxos que poden bloquejar un usuari:
- verificació de nou compte;
- restabliment de contrasenya;
- invitació a equip o espai de treball;
- confirmació de canvi d'email;
- enllaç d'inici de sessió o codi d'un sol ús;
- alerta de seguretat després d'una acció sensible.
Per a cada flux, prova el camí feliç, una credencial caducada o reutilitzada i un error del costat del destinatari. Això captura més defectes reals que enviar desenes de missatges idèntics de camí feliç.
Utilitza una bústia per escenari
Reutilitzar una sola adreça crea ambigüitat. Un antic missatge de restabliment pot confondre's amb el més recent, i les proves paral·leles poden consumir els enllaços de l'altre.
Genera una adreça única per a cada cas de prova o execució de prova. Registra-la juntament amb el número de build, l'entorn, la configuració regional i l'escenari. Si una prova falla, l'adreça esdevé part de l'evidència i pot ser inspeccionada abans que expiri la retenció.
No utilitzis adreces reals de clients a l'entorn de staging. Això comporta missatges no desitjats, contamina les analítiques i dificulta la neteja automàtica.
Comprova l'envolupant abans del cos
Abans de fer clic a qualsevol cosa, verifica:
- El missatge s'ha enviat a l'adreça exacta creada per a aquesta prova.
- El domini del remitent és el esperat per a l'entorn.
- L'assumpte identifica l'acció sense exposar dades sensibles.
- Només ha arribat el nombre esperat de missatges.
- La marca de temps és posterior a l'acció que l'ha generat.
Aquests controls detecten problemes de rutes i duplicacions abans que un analitzador del cos els amagui.
Prova el contingut tal com l'usuari el veu
Obre el missatge tant en una vista estreta com en una àmplia. Verifica que l'acció principal sigui visible, que la versió de text pla sigui comprensible i que adreces o URLs llargues no trenquin el disseny.
Per a un flux basat en codi, verifica que el codi més nou funcioni una vegada i falli després d'usar-lo. Per a un flux basat en enllaç, confirma l'amfitrió i l'entorn abans d'obrir-lo. Un missatge de staging que apunta a producció és un bloqueig de llançament encara que l'enllaç funcioni tècnicament.
Comprova també els detalls menys glamurosos: comportament del "reply-to", contacte de suport, redacció de caducitat, configuració regional i el nom del compte o espai de treball que apareix al missatge.
Casos negatius que valen la pena
Proves negatives útils inclouen:
- sol·licitar un segon codi i confirmar que el primer queda invalidat;
- obrir un enllaç caducat;
- obrir el mateix enllaç dues vegades;
- canviar l'estat del compte abans d'utilitzar el missatge;
- convidar una adreça que ja pertany a un membre;
- introduir una adreça no suportada o mal formada;
- retardar l'entrega prou com per superar el límit de caducitat.
Aquestes proves exposen condicions de carrera i missatges d'error enganyosos que una simple comprovació de bústia mai trobarà.
Separa la fallada del producte del retard de lliurament
Quan falta un missatge, conserva les marques de temps per a l'acció de l'usuari, l'enviament a la cua de l'aplicació, la transferència al proveïdor i l'arribada a la bústia quan aquests senyals estiguin disponibles. Una captura de pantalla d'una bústia buida només demostra que el missatge no era visible en aquell moment.
Utilitza la seqüència de diagnòstic a Correu de Verificació No Arriba: Troba el Pas Trencat abans d'obrir un problema vague de "correu trencat".
Què automatitzar
Automatitza contractes estables:
- genera una adreça única;
- desencadena l'acció del producte;
- consulta amb un temps d'espera limitat i retrocés exponencial;
- comprova que el remitent i l'assumpte siguin els esperats;
- llegeix el missatge més recent que coincideixi;
- valida el codi o enllaç contra el producte;
- desa evidència útil de fallada;
- neteja.
Mantén la revisió visual, la qualitat del text i el comportament inusual del client en una passada manual enfocada. L'automatització és bona per a la repetició, no per al gust.
Automatització Fiable de l'API de Bústies Temporals cobreix la part de l'API, incloent consultes i neteja.
Un informe de fallada útil
Un informe que els desenvolupadors puguin actuar conté l'escenari, l'entorn, l'adreça, l'hora del desencadenament, el remitent esperat, els missatges observats, l'última hora de consulta, l'estat de la resposta i una captura de pantalla o fragment del cos sanititzat. Mai adjuntis secrets en viu o enllaços de verificació reutilitzables a un problema públic.
L'objectiu no és demostrar que el correu electrònic és poc fiable. És identificar quin contracte ha fallat i deixar un camí reproduïble cap a la solució.