E-mail temporaire pour les tests : comment développeurs et équipes QA vérifient les parcours d'inscription

Tout produit qui envoie des e-mails a besoin de quelqu'un pour s'inscrire, encore et encore, avec une adresse neuve. Les développeurs se servent de leur propre Gmail avec une étiquette plus, les testeurs QA tiennent un tableur de comptes jetables et les chefs de produit empruntent la boîte d'un collègue. Pour une tâche précise, une adresse e-mail temporaire de test est plus rapide que tout cela : voir exactement ce que reçoit un nouvel utilisateur depuis votre configuration d'envoi de production ou de préproduction.

Nous gérons les serveurs de messagerie de PureTempMail : les limites ci-dessous sont donc nos vrais réglages, pas des suppositions. Ce guide montre où une boîte temporaire publique s'insère dans un plan de test, un passage manuel faisable en cinq minutes, la checklist que nous appliquerions à nos propres e-mails d'inscription et les cas où il vaut mieux prendre un autre outil.

La place d'une boîte temporaire parmi vos options de test

Il existe cinq façons courantes de donner une adresse à un compte de test. La plupart des équipes finissent par en utiliser deux ou trois, à différentes étapes d'une même version.

Une boîte temporaire comble un manque que les autres laissent : un vrai message, envoyé par votre vrai fournisseur d'envoi, qui arrive sur un domaine que vous ne contrôlez pas et s'affiche dans un navigateur en quelques secondes. C'est ce qui se rapproche le plus de ce que voit un nouveau client, sans créer un compte de plus quelque part.

Un test manuel avec PureTempMail

Voici le déroulé que nous conseillons pour vérifier un parcours d'inscription à la main. Comptez environ cinq minutes par passage.

1. 1

   Ouvrez une boîte neuve pour chaque utilisateur de test

   Ouvrez PureTempMail dans une fenêtre de navigateur séparée. Une nouvelle adresse est créée au chargement. La boîte est mémorisée par navigateur : appuyez donc sur Nouveau pour chaque utilisateur de test, ou utilisez une fenêtre privée quand deux testeurs partagent une machine.

2. 2

   Notez l'adresse à côté du cas de test

   Collez l'adresse dans votre cas de test ou votre ticket avant de l'utiliser. Si un testeur demande plus tard pourquoi l'e-mail de réinitialisation n'est jamais arrivé, vous devez savoir dans quelle boîte il est parti.

3. 3

   Faites l'inscription et déclenchez tous les e-mails possibles

   Remplissez le formulaire, puis demandez les e-mails qu'un nouvel utilisateur peut provoquer lors de sa première session : renvoi de la vérification, mot de passe oublié, connexion par lien magique, demande de changement d'adresse. Chacun est un modèle distinct qui peut casser à lui seul.

4. 4

   Surveillez la boîte sans actualiser

   Le nouveau courrier est poussé vers la page par une connexion en direct dès que notre serveur l'accepte : le moment où un message apparaît est donc proche de son heure réelle de distribution. Notez combien de temps chacun a pris. La page Comment ça marche explique le parcours de distribution.

5. 5

   Ouvrez chaque message dans les deux vues

   Lisez-le en HTML, puis passez en Texte brut. La vue texte est celle sur laquelle se rabattent certains logiciels et lecteurs d'écran, et c'est là qu'une partie texte manquante ou un code illisible se remarque en premier. Cliquez sur chaque lien et vérifiez où il mène.

6. 6

   Prolongez si le parcours est lent

   Les séquences automatisées, les validations différées et les relances du deuxième jour demandent plus de temps. Appuyez sur +1 h pour remettre le minuteur à une heure pleine. Vous pouvez le refaire jusqu'à 24 heures après la création de la boîte.

7. 7

   Laissez-la expirer, puis testez le rebond

   Après expiration, notre serveur refuse le courrier adressé à cette adresse dès l'étape SMTP, avec une erreur permanente "No such mailbox". Envoyez-lui encore un e-mail et vérifiez que votre app ou votre fournisseur d'envoi enregistre un rebond permanent (hard bounce) et cesse d'écrire à cet utilisateur.

La checklist de test des e-mails d'inscription

Voici les vérifications que nous ferions sur les e-mails d'inscription de n'importe quel produit avant une mise en production. Chacune se repère facilement dans une vraie boîte de réception et s'oublie facilement lors d'une revue de code.

• Code ou lien de vérification. Il arrive, le code est lisible en texte brut, le lien fonctionne une fois, et un second clic affiche un message clair au lieu d'une page d'erreur.
• Liens magiques et codes à usage unique. Un nouveau lien invalide l'ancien, un lien expiré explique quoi faire ensuite, et l'ouverture du lien dans un autre navigateur se comporte comme vous l'avez prévu.
• Réinitialisation du mot de passe. L'e-mail indique à quel compte il se rapporte, le lien expire, et une demande pour une adresse non inscrite ne révèle pas si cette adresse possède un compte.
• E-mails de bienvenue et séquences automatisées. Le premier arrive après la vérification, pas avant, et les étapes suivantes ne se déclenchent pas pour les utilisateurs qui n'ont jamais confirmé.
• Parties HTML et texte brut. Les deux existent, les deux disent la même chose, et rien d'important ne se trouve uniquement dans une image. Les images distantes se chargent dans notre vue HTML : vous pouvez donc les y vérifier, puis utiliser Texte brut pour voir le message sans elles.
• Pièces jointes. Factures et PDF arrivent avec des noms de fichier et des types de contenu sensés. Gardez les fichiers de test sous 1 Mo par message, ou envoyez un lien de téléchargement, ce qui est de toute façon plus agréable pour les vrais utilisateurs.
• Destination des liens. Aucun lien d'un e-mail de production ne pointe vers localhost, un nom d'hôte interne ou un domaine de préproduction, et les redirections de suivi mènent à la bonne page.
• En-têtes de désabonnement. Les e-mails marketing et les séquences automatisées contiennent un lien de désabonnement fonctionnel et, pour les expéditeurs en masse, l'en-tête de désabonnement en un clic List-Unsubscribe décrit dans la RFC 8058, que les consignes de Google pour les expéditeurs exigent des expéditeurs en masse. Les e-mails transactionnels, comme les réinitialisations, ne doivent pas être bloqués par un désabonnement.
• Délai de distribution. Les e-mails de vérification qui mettent plus d'une ou deux minutes font perdre des utilisateurs. Si l'un d'eux est lent, vérifiez si votre app met le courrier en file derrière d'autres tâches ou si le fournisseur bride les nouveaux expéditeurs.
• Vos propres limites de débit. Martelez le bouton de renvoi. L'app doit le plafonner et demander à l'utilisateur de patienter, plutôt que d'envoyer dix codes ou d'échouer en silence.
• Réutilisation d'une adresse. Inscrivez-vous deux fois avec la même adresse dans une même session et vérifiez la seconde tentative : un parcours clair du type "déjà inscrit", et pas de second compte.
• Votre règle contre les domaines jetables. Si votre produit bloque les adresses temporaires, vérifiez que le message d'erreur est clair et qu'il ne bloque pas aussi de vrais fournisseurs par erreur. Plus de détails ci-dessous.

Nos limites, et ce qu'elles impliquent pour un test

Ce sont les réglages réels de nos serveurs. Organisez vos tests en fonction.

Durée de vie

Une heure à partir de la création. +1 h la remet à une heure pleine, jusqu'à 24 heures après la création. Assez pour une session, pas pour un compte de test que vous réutiliserez au prochain sprint.

Messages

Jusqu'à 50 messages et 5 Mo par boîte. Le nouveau courrier est refusé dès que l'une des deux limites est atteinte : un test de charge visant une seule adresse cesse donc vite de compter. Ouvrez une nouvelle boîte par utilisateur de test.

Taille des messages

Jusqu'à 1 Mo par e-mail, pièces jointes comprises. Seules les 10 premières pièces jointes sont conservées.

Réception seule

L'adresse ne peut ni envoyer ni répondre. Les parcours où l'utilisateur doit répondre par e-mail, comme les fils de tickets de support, ne peuvent pas être testés de bout en bout ici.

Domaine

Un seul domaine pour toutes les adresses. Si votre produit bloque les domaines temporaires connus, il bloquera le nôtre, ce qui est utile quand c'est justement le comportement que vous voulez tester.

Nouvelles boîtes

Cinq nouvelles boîtes par minute depuis une même adresse IP. Une équipe QA derrière une seule connexion de bureau se partage ce quota.

Suppression

Après expiration, un nettoyage qui s'exécute toutes les cinq minutes supprime la boîte, ses messages et ses pièces jointes. Faites des captures d'écran avant la fin du minuteur si vous avez besoin de preuves pour un rapport de bug.

Automatisation

Il n'existe pas d'API publique pour accéder aux boîtes par script. PureTempMail est conçu pour une personne devant un navigateur : c'est pourquoi les suites automatisées ont leur place sur les outils présentés plus bas.

Vérifier SPF, DKIM et DMARC sur vos e-mails de test

Un message qui s'affiche bien peut quand même échouer à l'authentification et finir en spam chez les vrais utilisateurs. Pour le vérifier, envoyez le même e-mail à une boîte qui montre la source brute, par exemple avec Afficher l'original dans Gmail, et collez les en-têtes dans notre analyseur d'en-têtes e-mail. Il indique si SPF, DKIM et DMARC ont réussi, signale un Reply-To sur un autre domaine et montre où la distribution a ralenti. L'analyse se fait dans votre navigateur : les en-têtes ne nous sont donc pas envoyés.

Tester votre propre blocage des domaines jetables

Beaucoup d'équipes ajoutent une vérification anti-e-mail jetable à leur formulaire d'inscription sans jamais la tester avec une vraie adresse temporaire. Une boîte temporaire est l'entrée de test évidente.

• Vérifiez la formulation. Le refus doit dire quoi utiliser à la place, par exemple "Veuillez utiliser une adresse personnelle ou professionnelle". Un simple "E-mail invalide" pousse les utilisateurs honnêtes à chercher une faute de frappe qui n'existe pas.
• Vérifiez les faux positifs. Essayez des adresses chez de petits fournisseurs régionaux et sur des domaines d'entreprise personnalisés. Les listes de blocage qui fonctionnent par motifs les attrapent parfois.
• Vérifiez chaque point d'entrée. La même règle doit s'appliquer au formulaire d'inscription, au réglage de changement d'adresse, aux invitations et à l'API, sinon les gens passeront simplement par le chemin que vous avez oublié.
• Demandez-vous si le blocage est vraiment nécessaire. Notre article pourquoi les sites bloquent les e-mails jetables détaille les coûts qui le justifient et les cas où il ne fait que vous coûter des utilisateurs honnêtes.

Quand une boîte temporaire publique n'est pas le bon outil

Dans ces cas-là, utilisez autre chose.

• Tout ce qui contient de vrais secrets ou des données clients. Jetons de production, vraies factures, invitations administrateur. Utilisez une sandbox que seule votre équipe peut lire.
• Tests automatisés et CI. Faites pointer l'app vers un capteur local comme Mailpit en développement et en CI, et vers une sandbox hébergée comme Mailtrap ou Mailosaur quand les tests doivent tourner sur un environnement déployé. MailHog, l'ancien capteur local, n'est plus maintenu, et Mailpit est son remplaçant habituel.
• Environnements de préproduction contenant des copies de vraies données utilisateurs. Le problème, ce sont les données copiées. Anonymisez-les et redirigez le courrier de préproduction vers un capteur, pour qu'un test n'écrive jamais à un vrai client.
• Comptes de test que vous devez conserver. Un compte de démo pour l'équipe commerciale ou un compte de vérification pour un app store a besoin d'une adresse qui fonctionnera encore le mois prochain. Utilisez l'adressage plus sur une boîte d'équipe ou un catch-all sur un domaine de test qui vous appartient.
• Données de test qui ne doivent jamais être distribuées. Pour les données d'amorçage et les tests unitaires, utilisez les domaines réservés comme example.com et le domaine de premier niveau .test prévus par la RFC 2606. Le courrier qui leur est adressé ne va nulle part, par conception.

Sources

• Mailpit sur GitHub, l'outil de test d'e-mails avec API pour les développeurs, et ses notes sur le remplacement de MailHog.
• Documentation de Mailtrap Email Sandbox.
• Bibliothèques clientes de Mailosaur sur GitHub.
• RFC 8058, Signaling One-Click Functionality for List Email Headers.
• Google, Consignes pour les expéditeurs d'e-mails.
• RFC 2606, Reserved Top Level DNS Names.
• La durée de vie des boîtes, leurs limites de taille et de nombre, les limites de débit, le refus SMTP après expiration et la fréquence du nettoyage proviennent de la configuration des serveurs de PureTempMail, également résumée dans la FAQ.