Vendredi soir, une heure avant la mise en production. La cheffe de produit écrit sur la messagerie de l'équipe « Je ne reçois pas l'e-mail de réinitialisation du mot de passe. » Un développeur essaie avec sa propre adresse et le message arrive. Une testeuse essaie à son tour et le reçoit aussi. Le problème n'est compris que plus tard. Tout le monde utilise les deux ou trois mêmes adresses depuis des mois, le système les considère comme « déjà vérifiées », et le parcours nouvel utilisateur ne se déclenche jamais. Personne n'a vraiment testé dans la peau d'un nouvel inscrit.
La scène est courante dans les équipes logicielles. Pour tester honnêtement les parcours qui passent par l'e-mail (inscription, activation, réinitialisation du mot de passe), le plus fiable est de repartir à chaque fois d'une adresse vierge, jamais vue par le système. C'est exactement là qu'un e-mail temporaire rend service. Disons aussi d'emblée où il ne sert à rien, parce qu'un développeur qui arrive avec de mauvaises attentes sera déçu en dix minutes.
Ce que l'e-mail temporaire simplifie en test manuel
Inscription et activation
Vous voulez dérouler le scénario nouvel utilisateur de bout en bout. Le formulaire est rempli, l'e-mail de vérification part, on clique sur le lien, le compte est activé. Il suffit d'ouvrir la page d'accueil de Geçici Mail et l'adresse se crée toute seule, vous la copiez avec le bouton COPIER et la collez dans le formulaire d'inscription. La boîte se rafraîchit toutes les 5 secondes. Dans nos propres tests, un e-mail envoyé apparaît en moyenne en 3 à 5 secondes. Si vous ne voulez pas attendre, le bouton ACTUALISER met la boîte à jour immédiatement.
Ce qu'il faut vérifier va au-delà de « l'e-mail est-il arrivé ? » :
- Le lien de vérification pointe-t-il vers le bon environnement ? Un e-mail envoyé depuis la préproduction qui renvoie vers la production, c'est un bug classique.
- Le lien est-il à usage unique ? Au second clic, un message compréhensible s'affiche-t-il ?
- Que se passe-t-il avec un jeton expiré ? Laissez le lien de côté un moment, puis réessayez.
- L'objet et le nom de l'expéditeur sont-ils clairs dans la boîte de réception de l'utilisateur ?
Réinitialisation du mot de passe
Le cas le plus souvent oublié, c'est quand on envoie plusieurs demandes de réinitialisation d'affilée à la même adresse, les anciens liens sont-ils invalidés ? Avec une adresse temporaire, envoyez trois demandes, attendez les trois e-mails, puis cliquez sur le lien du premier. S'il fonctionne encore, vous tenez peut-être une faille de sécurité. Faire ce test dans votre boîte personnelle l'encombre et mélange tout avec vos anciens messages.
Le rendu réel du modèle HTML
Prévisualiser un modèle d'e-mail dans le navigateur et le voir dans une boîte de réception, ce n'est pas la même chose. Sur Geçici Mail, les e-mails HTML sont affichés de façon sécurisée. Les scripts sont supprimés et le message s'ouvre dans un cadre isolé, séparé du reste de la page. Si une partie de votre modèle dépend d'un script, vous le verrez tout de suite. De toute façon, la plupart des clients de messagerie n'exécutent pas de scripts ; si votre modèle s'affiche mal ici, il y a de bonnes chances qu'il pose aussi problème ailleurs.
Soyons francs, une seule boîte de réception ne montre pas toutes les différences entre clients de messagerie. Clients de bureau, applications mobiles, mode sombre, chacun a ses bizarreries. L'e-mail temporaire vous donne un « premier vrai regard », pas un test de compatibilité complet.
Scénarios à plusieurs utilisateurs
Système d'invitation, ajout de membres à une équipe, notification de message entre deux utilisateurs… Pour tester tout cela, il faut plusieurs adresses. Chaque profil de navigateur ou fenêtre de navigation privée peut correspondre à une adresse distincte. Par exemple, gardez l'adresse « administrateur » ouverte dans une fenêtre et celle de « l'utilisateur invité » dans une autre, puis vérifiez que l'invitation part vers la bonne personne avec le bon rôle. Le bouton SUPPRIMER abandonne l'adresse en cours et vous en donne une nouvelle ; pratique pour repartir de zéro quand vous en avez fini avec un utilisateur.
Les limites de l'e-mail temporaire pour une équipe de test
La première question des développeurs est presque toujours la même, « Vous avez une API ? » Non. Le service est pensé pour un usage manuel, depuis le navigateur. Si vous essayez de brancher vos scripts de test dessus, ce n'est pas l'outil adapté.
Les autres limites :
- Les pièces jointes ne sont pas affichées. Si vous testez un parcours avec facture PDF, billet ou certificat en pièce jointe, vous ne pourrez pas vérifier leur présence ici.
- Impossible d'envoyer des e-mails. Les parcours du type « répondez à cet e-mail », c'est-à-dire les systèmes qui traitent les réponses entrantes, ne peuvent pas être testés.
- L'adresse ne se choisit pas. Elle est générée au hasard ; si vous avez besoin d'une adresse respectant un format précis, ce n'est pas le bon endroit.
- Les e-mails ne sont pas conservés. Les messages reçus sont supprimés automatiquement au bout de 24 heures. Si vous devez garder la preuve d'un bug, faites une capture d'écran.
- Certains services refusent les domaines temporaires. Si l'application que vous testez applique ce filtre, rappelez-vous que ce n'est pas un bug mais votre propre règle.
Quel outil pour le test manuel et pour le test automatisé ?
Pour faire simple, l'e-mail temporaire sert aux tests où un humain regarde le résultat. Pour une chaîne de tests qui tourne à chaque commit, d'autres outils existent.
| Besoin | Outil adapté | Pourquoi |
|---|---|---|
| Dérouler à la main le parcours nouvel utilisateur | E-mail temporaire | Adresse vierge, aucune installation, prêt en quelques secondes |
| Rendu du modèle dans une vraie boîte de réception | E-mail temporaire | Affichage isolé, scripts supprimés ; premier contrôle rapide |
| Vérification automatique des e-mails en CI/CD | Outil local de capture SMTP | Les e-mails ne sortent pas, le code de test peut les lire |
| Contrôle des e-mails avec pièces jointes | Outil local de capture SMTP ou votre propre boîte de test | Les pièces jointes ne sont pas affichées dans l'e-mail temporaire |
| Délivrabilité et score de spam | Les outils de votre fournisseur d'envoi | Mesurer la configuration du domaine d'envoi est un autre travail |
Les outils locaux de capture SMTP recueillent les e-mails envoyés par votre application dans un faux serveur, sans les laisser partir sur Internet, et vous offrent une interface web ou un point d'accès lisible par vos tests. Il existe de nombreuses options open source qu'on lance en quelques minutes avec Docker dans l'environnement de développement. Dans vos tests automatisés, lire l'e-mail, extraire le lien et cliquer dessus doit passer par ce type d'outil. C'est plus rapide, et vous ne dépendez pas d'un service externe.
Le déroulé de test que nous recommandons
- Avant de commencer, ouvrez une nouvelle fenêtre de navigation privée et allez sur gecicimail.com.tr. L'adresse se crée automatiquement.
- Notez l'adresse et la clé de récupération dans votre fiche de test ou dans le ticket de votre outil de suivi.
- Remplissez le formulaire d'inscription avec cette adresse et observez à peu près le délai d'arrivée de l'e-mail.
- Ouvrez le message et vérifiez objet, nom de l'expéditeur, environnement cible du lien, rendu en largeur mobile.
- Cliquez sur le lien, puis cliquez une seconde fois sur le même lien. Notez le comportement.
- Déclenchez plusieurs réinitialisations de mot de passe d'affilée et testez les anciens liens.
- Faites les captures d'écran nécessaires ; les e-mails seront supprimés au bout de 24 heures.
- Pour le scénario suivant, obtenez une nouvelle adresse avec SUPPRIMER.
Si l'e-mail n'arrive pas du tout, le problème ne vient pas forcément de votre code. File d'envoi, filtre sur le domaine ou mauvaise configuration d'environnement, les pistes sont réunies dans l'article je ne reçois pas d'e-mail sur mon adresse temporaire.
Ne testez pas avec de vraies données utilisateurs
Une dernière remarque, peut-être la plus importante. Copier de vraies adresses d'utilisateurs depuis la production vers l'environnement de test, c'est le chemin le plus court pour envoyer un jour, par erreur, des e-mails de test à de vraies personnes. Ces adresses sont aussi des données personnelles, ce qui pose des questions au regard du RGPD. Utiliser une adresse temporaire pour les tests manuels et un outil de capture local pour les tests automatisés supprime ce risque dès le départ.
Questions fréquentes
Geçici Mail propose-t-il une API ?
Non, Geçici Mail ne propose pas d'API. Le site est conçu uniquement pour une utilisation manuelle depuis le navigateur.
Puis-je utiliser un e-mail temporaire dans mes tests automatisés (CI) ?
Nous ne le recommandons pas. Pour les tests automatisés, un outil de test SMTP qui capture localement les e-mails de votre application est plus rapide et plus fiable.
Tester mon modèle d'e-mail HTML avec un e-mail temporaire donne-t-il un résultat fiable ?
Cela donne une bonne première idée du rendu dans une vraie boîte de réception, puisque les scripts sont supprimés et l'e-mail s'ouvre dans un cadre isolé. En revanche, cela ne montre pas toutes les différences entre clients de messagerie.
Puis-je voir les e-mails avec pièces jointes ?
Non, les pièces jointes ne sont pas affichées. Vérifiez les parcours avec pièces jointes dans votre propre boîte de test ou dans un outil local de capture SMTP.
Puis-je revenir le lendemain à la même adresse de test ?
Oui, si vous avez noté la clé de récupération, vous pouvez y revenir via « Récupérer l'e-mail ». Comme les e-mails reçus sont supprimés au bout de 24 heures, les anciens messages peuvent toutefois avoir disparu.