Tests d’inscription / état du code de vérification

Comment tester le renvoi des codes de vérification ?

Un bouton de renvoi qui fonctionne ne garantit pas que le processus est correct. Testez séparément le délai d’attente, la validité des anciens codes et la destination des emails après un changement d’adresse.

Notes pratiquesEnviron 8 min

Lors d’un test de code de vérification à l’inscription, réussir le parcours initial prouve seulement que l’email peut être reçu. Cela ne garantit pas que le renvoi gère correctement les changements d’état. Commencez par vérifier la règle prévue : seul le dernier code est-il valide, ou tous les codes non expirés le sont-ils ? Concevez ensuite vos cas de test. Sans cette précaution, conclure qu’un ancien code encore accepté est une erreur peut revenir à tester une exigence qui n’existe pas.

Préparez une adresse distincte pour chaque série de tests

Créez une nouvelle adresse avec une boîte mail temporaire de test Notez l’heure actuelle et la durée de validité attendue, puis déclenchez le premier email depuis la page d’inscription du système testé. Dès qu’il apparaît dans la boîte de réception, relevez son objet, son heure d’arrivée et les indications de validité dans son contenu. Pour le scénario suivant, utilisez une nouvelle adresse afin que les anciens messages des différents essais ne se retrouvent pas mélangés dans la même liste.

L’adresse n’est pas le seul état à suivre dans le processus de vérification : l’email saisi par l’utilisateur, le code actuel, le nombre d’envois, l’heure du prochain renvoi autorisé et l’étape de la page de connexion peuvent aussi changer. Dans votre tableau de suivi, ajoutez une colonne « adresse actuelle » et une colonne « numéro d’envoi » pour chaque événement. Si nécessaire, notez également l’identifiant de requête renvoyé par le système testé, mais ne copiez jamais un code de vérification complet dans un document partagé.

Délai d’attente : testez le compte à rebours affiché et la vraie limite

Cliquez plusieurs fois ou validez rapidement au clavier dès que le compte à rebours s’affiche, puis vérifiez si plusieurs emails sont envoyés. Changez d’onglet, actualisez la page, coupez puis rétablissez la connexion : vérifiez si le compte à rebours côté navigateur reste synchronisé avec la limite côté serveur. Un bouton grisé ne prouve pas que les envois abusifs sont empêchés : si rouvrir la page d’inscription suffit à contourner la limite, l’utilisateur risque de recevoir une série d’emails difficiles à distinguer.

Si le produit indique qu’un nouvel envoi est possible toutes les minutes, faites un essai une seconde avant la fin du délai, puis un autre une seconde après. Notez le message affiché et le nombre réel de nouveaux emails ; ne confondez pas les variations du réseau avec une seconde de moins au compte à rebours. Pour tester les limites côté serveur, utilisez un environnement de test autorisé par votre équipe et évitez de déclencher des envois répétés en masse vers de vraies adresses.

Ancien et nouveau code : définissez la règle avant de vérifier le résultat

À l’arrivée du premier email, appelez son code A, puis déclenchez un renvoi B dès que celui-ci est autorisé. Vérifiez que les deux emails concernent le même compte et le même environnement. Saisissez d’abord A, puis B, et observez pour chacun si la validation aboutit et quel message la page affiche. Si le premier email arrive avec un léger retard, déterminez l’ordre des codes selon leur numéro d’envoi, et non leur ordre dans la liste. Vous pouvez consulter la méthode de suivi chronologique des emails d’inscription pour reconstituer l’ordre d’arrivée.

Définissez les résultats attendus pour trois cas : le produit invalide l’ancien code dès l’envoi du nouveau ; il accepte les deux codes pendant leur période de validité respective ; ou seul le lien du dernier email renvoyé est utilisable. Une équipe ne doit pas mélanger ces trois règles. Si le comportement attendu n’est pas clairement documenté, demandez une clarification plutôt que de laisser chacun décider des critères de réussite ou d’échec des tests.

Saisissez ensuite volontairement un code erroné : le message doit permettre à l’utilisateur de comprendre s’il s’agit d’une erreur, d’une expiration, d’une limite de fréquence ou d’un compte déjà vérifié. Ne laissez apparaître aucun code encore utilisable ni lien d’activation complet dans les captures partagées. Pour le test, notez seulement le numéro de l’email et le résultat de la vérification.

Renvoi après changement d’adresse : vérifiez la destination

Sur la page de saisie du code, choisissez de modifier l’adresse et remplacez-la par une autre adresse de test distincte. Après validation, vérifiez que le nouvel email est envoyé uniquement à cette adresse, que l’interface affiche la nouvelle adresse et que le code reçu à l’ancienne permet ou non de valider la nouvelle inscription. Si le produit autorise le retour à l’ancienne adresse, observez toute la transition d’état au lieu de vérifier uniquement l’objet de l’email.

Si l’ancienne adresse continue de recevoir des emails de renvoi après sa modification, le problème peut venir de l’association au compte, d’une tâche en file d’attente ou d’un champ conservé côté interface. Conservez des versions expurgées des deux adresses de réception, l’heure de chaque clic et l’adresse cible affichée à l’écran. Vous pourrez ainsi distinguer une tâche simplement retardée d’un envoi réellement dirigé vers la mauvaise adresse.

Testez les cas limites : expiration et soumissions répétées

Saisissez A et B juste avant puis juste après leur expiration, et notez si le système se base sur l’heure de génération du code, celle de son envoi ou celle de sa saisie. Après validation réussie, le système doit, conformément aux règles du produit, refuser une nouvelle soumission du même code ou indiquer clairement que l’opération est terminée. Le bouton Retour du navigateur ne doit pas permettre d’activer le compte une seconde fois. Si l’inscription est accessible depuis plusieurs interfaces, comme le web mobile et le web sur ordinateur, vérifiez que les délais et l’état des anciens codes sont cohérents d’un appareil à l’autre.

Une adresse de test temporaire est disponible pendant 3 heures par défaut, ce qui convient à une vérification d’inscription ponctuelle. Si vos tests de régression s’étendent sur plusieurs jours ou si vous devez consulter des emails déjà reçus, consultez d’abord le planificateur de durée de vie des boîtes mail de test. Pour conserver les messages plus longtemps, optez pour un alias de transfert ou une boîte de test gérée par l’équipe, plutôt que de compter sur une adresse temporaire déjà expirée.

Terminez par un compte rendu reproductible

Consignez un événement par ligne sous la forme « prérequis — action — résultat attendu — résultat obtenu — preuve visible ». Les prérequis précisent l’environnement, l’état du compte et l’email déjà reçu. Distinguez les actions : cliquer sur Envoyer, demander un renvoi, modifier l’adresse ou saisir un code. Les résultats comprennent le compte à rebours, l’adresse de réception et le message d’erreur. Une suite de tests complète couvre aussi la première inscription, une inscription répétée et l’activation ; vous pouvez vous appuyer sur la liste de tests du parcours d’inscription pour repérer les oublis.

Si le renvoi fonctionne mais que l’utilisateur ne parvient toujours pas à se connecter, notez de quel code il s’agit, à quelle heure il a été saisi et quelle adresse la page affichait à ce moment-là. L’équipe de développement pourra ainsi localiser les incohérences d’état au lieu de recevoir un vague signalement indiquant que « le code ne fonctionne pas de temps en temps ».

Commencez par un premier essai dans une boîte vide

Utilisez une adresse dédiée, notez le premier envoi et le renvoi, puis vérifiez l’ancien code selon les règles de votre produit.

Obtenir une adresse de test