Quelque part dans votre suite de tests, il existe un flux d'inscription qui n'a jamais été testé avec une vraie boîte de réception. L'e-mail de confirmation est envoyé, le test réussit car l'API a renvoyé 200 et personne ne vérifie si le lien fonctionne, si le message s'affiche ou s'il atterrit dans le spam.
Les comptes de test ne doivent pas résider dans votre boîte de réception personnelle. Mais la solution évidente – pointer tout vers une adresse jetable – n’est qu’à moitié juste. Voici quand une boîte de réception temporaire est utile, quand un récepteur de messagerie local est meilleur et comment ne pas déclencher votre propre liste de blocage.
Commencez par ce que vous testez
Le bon outil découle de la question :
| Question | Meilleur outil |
|---|---|
| L'e-mail de confirmation s'affiche-t-il correctement et établit-il un lien ? | Récepteur de messagerie local (Mailpit, MailHog) |
| La livraison fonctionne-t-elle via un vrai fournisseur et un vrai DNS ? | Boîte de réception jetable |
| Le flux fonctionne-t-il sur un téléphone, avec le timing d'un utilisateur réel ? | Boîte de réception jetable |
| Puis-je inspecter les en-têtes bruts et les pièces jointes ? | Récepteur de courrier local |
| Un domaine jetable sera-t-il accepté par mon formulaire d'inscription ? | Cela dépend de votre propre liste de blocage |
Quand une boîte de réception jetable est la bonne solution
- Vérifications de bout en bout.Vous voulez voir ce qui arrive réellement sur Internet, et non ce que votre serveur SMTP local a reçu.
- Tests de fumée de délivrabilité.Envoyez depuis votre fournisseur de production à une adresse jetable et confirmez qu'il n'atteint pas le spam ou n'est pas abandonné.
- Tests mobiles.Une boîte de réception temporaire consiste à appuyer sur un téléphone ; un récepteur local nécessite un tunnel et un changement de configuration.
- Assurance qualité manuelle.Un testeur peut générer une adresse, compléter le flux et lire le courrier sans toucher à un compte de test partagé.
Quand un évier local est meilleur
Si vous affirmez le contenu du message, un récepteur local est plus rapide et plus fiable. Mailpit ou MailHog vous offre une API, un MIME brut, une inspection des pièces jointes et aucune limite de débit. Vous pouvez exécuter une centaine d’inscriptions en boucle sans vous soucier d’un fournisseur qui vous limite ou d’un domaine bloqué.
Le compromis est qu’un puits local contourne le véritable chemin de livraison. Il ne vous dira pas que votre enregistrement SPF est erroné, que votre domaine d'envoi est sur une liste de blocage ou que Gmail classe votre e-mail de confirmation sous Promotions.
Utilisez les deux, dans cet ordre
- Récepteur local pour la logique.Affirmez le lien, le jeton, l'expiration et le code HTML rendu. C'est la boucle rapide que vous exécutez à chaque commit.
- Boîte de réception jetable pour la livraison.Exécutez le même flux contre le staging avec un vrai fournisseur et une adresse temporaire. Vérifiez le placement dans la boîte de réception, la réécriture des liens et le rendu mobile.
- Véritable boîte aux lettres pour le contrôle final.Une fois par version, utilisez une adresse sur Gmail, Outlook et un domaine d'entreprise. C’est là que résident les bugs étranges spécifiques au client.
Ne bloquez pas vos propres tests
Si votre produit bloque les domaines jetables – et beaucoup le font – votre propre contrôle qualité échouera avant de démarrer. Deux options :
- Ajoutez vos domaines de test à la liste blanche lors de la préparation.Conservez la liste de blocage de production intacte, mais laissez votre environnement de test accepter les adresses utilisées par vos testeurs.
- Utilisez un domaine de test dédié.Un sous-domaine que vous contrôlez, acheminé vers un récepteur, est plus propre que d'affaiblir la règle de production.
Ne désactivez jamais la liste de blocage globalement pour réussir un test. C’est ainsi qu’un raccourci temporaire en matière d’assurance qualité devient un trou permanent.
Des choses qui cassent dans les vraies boîtes de réception
Voici les échecs qu’un récepteur local ne vous montrera jamais :
- Réécriture de liens.Les passerelles de sécurité de messagerie réécrivent chaque URL. Votre lien magique peut arriver enveloppé et brisé.
- Blocage d'images.Le logo disparaît et la mise en page s'effondre autour de lui.
- Mode sombre.Une carte blanche sur fond blanc devient un rectangle blanc.
- Codes longs.Un code à six chiffres suffit ; un jeton de 64 caractères s'enroule et ressemble à un lien rompu.
- Délai d'expiration.Un code qui expire au bout de dix minutes est inutilisable si la livraison prend quatre.
- Placement de spam.Les échecs d'authentification, un nouveau domaine d'envoi ou un mot déclencheur peuvent envoyer un e-mail transactionnel comme spam.
Une petite liste de contrôle pour la prochaine version
- Le lien de confirmation ouvre le bon environnement et connecte l'utilisateur une fois.
- Le code expire exactement lorsque l’interface utilisateur l’indique.
- Renvoyer fonctionne et son tarif est limité.
- Le message s'affiche à une largeur de 320 px avec des images bloquées.
- Une alternative en texte brut existe et contient le même lien.
- Les liens de désabonnement et de préférences fonctionnent pour le courrier marketing, pas seulement pour les transactions.
- L'adresse peut être modifiée après l'inscription.
Les tests d’e-mails ne sont pas glorieux et sont presque toujours ignorés. Les équipes qui le font détectent les échecs que les utilisateurs ne signalent jamais – ils partent simplement. Si vous avez besoin d'une vraie boîte mail pour le pass de livraison,générer un ici; pour la passe logique, conservez le récepteur local. Et si vous vous demandez si votre propre utilisation des adresses jetables est équitable,cet article sur les essaistrace la ligne.