Comment tester l’ordre d’arrivée des e-mails d’inscription ?

Lors des tests d’inscription, les problèmes les plus difficiles à reproduire ne sont souvent pas des e-mails complètement perdus, mais des messages reçus dans un ordre différent de leur envoi. Le premier arrive en retard, le second plus tôt ; la personne ouvre celui qui apparaît en haut de la liste, mais saisit un code déjà expiré. Pour repérer ces cas, attribuez une adresse de réception vierge à chaque série de tests et consignez en parallèle les événements de la page et ceux de la boîte de réception.

Définir le point de départ du test

Avant l’envoi, notez l’heure du navigateur, l’environnement de test, le compte d’inscription et l’adresse de réception. Utilisez la boîte de réception de test temporaire pour obtenir une nouvelle adresse. Vérifiez qu’elle ne contient aucun e-mail de la série précédente, puis saisissez-la dans le formulaire d’inscription. N’attribuez pas la même adresse à plusieurs tests exécutés en parallèle : une fois les messages regroupés dans la même liste, il est difficile de savoir quel test a déclenché leur envoi.

Le message « Envoi réussi » affiché sur la page ne signifie pas forcément que l’e-mail a été remis à la personne. Il peut indiquer que la requête du navigateur a abouti ou que le message a simplement été ajouté à une file d’attente. Distinguez quatre moments : clic sur le bouton d’envoi, confirmation affichée sur la page, apparition de l’e-mail dans la boîte de réception et ouverture effective du message. Si votre équipe a accès aux journaux du serveur, notez aussi l’heure à laquelle le service de messagerie a accepté la requête, mais ne mélangez pas l’heure des journaux internes et le fuseau horaire local de la personne dans un même champ.

Consigner envoi et réception dans le même tableau

Une fiche de test minimale doit inclure le numéro de la requête, l’action effectuée, l’heure de l’action, l’objet de l’e-mail, l’heure à laquelle il apparaît dans la boîte de réception, la durée de validité indiquée dans le message et la requête associée au code effectivement saisi. Choisissez la précision horaire en fonction des besoins de votre système ; pour les renvois à quelques secondes d’intervalle, notez au moins les secondes. Conservez ces données uniquement dans un environnement de test contrôlé et ne publiez pas les codes bruts dans des tickets accessibles au public.

Il ne s’agit pas d’exiger que le service livre les e-mails à la seconde près, mais de documenter les problèmes avec des éléments concrets : si l’interface trie uniquement par heure de réception, l’e-mail A risque d’être pris pour le code le plus récent. Notez l’objet des deux e-mails, les indications dans leur contenu et les champs d’horodatage. Vérifiez que le produit précise clairement que « seul le dernier code est valide ».

Quels cas tester lors d’un renvoi ?

Clics répétés pendant le délai d’attente

Vérifiez d’abord si le bouton est désactivé et si le temps d’attente restant est indiqué. Pendant ce délai, cliquez plusieurs fois ou appuyez rapidement sur Entrée, puis vérifiez si un seul e-mail ou plusieurs sont envoyés. Sur mobile, testez aussi si le compte à rebours repart à zéro lorsque l’application passe en arrière-plan puis revient au premier plan. Le temps affiché doit correspondre au moment où l’envoi est de nouveau autorisé.

L’e-mail précédent arrive après le suivant

Utilisez successivement les codes des e-mails A et B pour effectuer la vérification, puis notez le résultat attendu et le message affiché pour chacun. Ne partez pas du principe que l’ancien code est toujours invalidé dès qu’un nouvel envoi est effectué : vérifiez d’abord le fonctionnement prévu par le produit, puis rédigez les assertions en conséquence. Il est surtout important que la personne puisse savoir quel e-mail correspond au champ de saisie actuel.

À l’approche de l’expiration

Le début du compte à rebours — à l’envoi ou à la réception — dépend des règles de l’application. Si l’e-mail promet une validité de dix minutes, effectuez des tests juste avant et juste après l’expiration. Si un retard dans la file d’attente retarde la réception, la durée d’utilisation réelle peut être nettement inférieure à celle annoncée. Notez à la fois les heures et les messages affichés sur la page : « expiration occasionnelle » ne suffit pas.

Quand un e-mail n’arrive pas, identifier où ça bloque

Vérifiez d’abord que l’adresse copiée dans le formulaire est complète et ne contient pas d’espace, puis confirmez que le formulaire l’a bien acceptée. Actualisez ensuite manuellement la boîte de réception et vérifiez que l’adresse n’a pas changé ou expiré. Si le prestataire fournit des journaux de remise, vérifiez s’il a accepté la demande d’envoi : le fait que la personne ne voie pas l’e-mail ne suffit pas à conclure à un problème de boîte de réception. Certains services peuvent refuser les domaines d’e-mails jetables ; il s’agit alors d’une règle de saisie, pas d’un retard de livraison.

Les nouvelles adresses sont valides 3 heures par défaut. Pour les tests de régression plus longs, commencez par estimer la fenêtre de test avec le planificateur de durée de vie. Si vous devez consulter les e-mails d’inscription le lendemain, n’utilisez pas une boîte de test qui sera supprimée : optez plutôt pour un alias de transfert permanent ou une adresse de test gérée par votre équipe. Pour couvrir l’inscription normale, les codes invalides et les comptes en double, suivez étape par étape la checklist de test des inscriptions.

Qu’inclure dans un rapport de chronologie destiné à l’équipe de développement ?

Indiquez l’environnement, une version anonymisée de l’adresse de test, les numéros de requête, les heures de chaque événement, les objets des e-mails reçus et le comportement attendu. Les captures d’écran doivent montrer uniquement les éléments de l’interface utiles au diagnostic. Ne partagez pas publiquement les codes, les adresses complètes ni les liens d’activation. Si le problème est reproductible, précisez « nombre de renvois, délai écoulé, e-mail arrivé en premier, code qui a fonctionné » : cela aidera davantage à diagnostiquer la file d’attente et la mise à jour de l’état qu’un simple « réception lente ».

Limitez chaque série de tests à une période définie et utilisez une nouvelle adresse à chaque nouvelle série. Ainsi, même si le retard vient finalement d’un tiers, vous pourrez expliquer à votre équipe ce que vous avez observé et ce qui n’est pas encore démontré.