Testez avec une adresse distincte :
renvois, expirations et exécutions parallèles
Une adresse par parcours : vos tests d’e-mails d’inscription ne seront plus perturbés par d’anciens codes, liens ou identités mis en cache. Voici une matrice d’AQ légère fondée sur une boîte de réception jetable, couvrant les scénarios normaux, les erreurs et le multilingue.
Ce processus convient aux environnements produits que vous êtes autorisé à tester. L’objectif n’est pas de créer des comptes en masse, mais de relier chaque identité de test, chaque e-mail et chaque résultat, afin de reproduire rapidement tout problème.
1. Commencez par établir une matrice des identités
Attribuez les adresses par parcours, et non par testeur. Utilisez une adresse distincte pour l’inscription normale, le premier renvoi, l’expiration du lien, le changement de langue et la lecture sur mobile ; créez aussi une nouvelle identité lorsque vous répétez un même parcours dans différents navigateurs. Ainsi, même si les e-mails arrivent dans le désordre, vous ne confondrez pas les résultats d’une session précédente avec ceux de la session en cours.
Dans la boîte de réception jetable RelayTmp, copiez l’adresse puis consignez-la immédiatement dans la ligne du cas de test. L’adresse dispose par défaut d’un compte à rebours clair, idéal pour une intégration sur quelques heures. Si le test doit durer plusieurs semaines ou nécessite de recevoir durablement des messages sous une même identité publique, utilisez plutôt une adresse e-mail que vous contrôlez à long terme ou un alias de transfert.
| Cas de test | Identité distincte | Vérification clé |
|---|---|---|
| Première inscription | Adresse A | Un e-mail, code valide et page de bienvenue cohérente |
| Renvoi du code | Adresse B | Délai clairement indiqué, règle concernant l’ancien code respectée |
| Expiration du lien de confirmation | Adresse C | Page d’expiration compréhensible et possibilité de relancer l’action |
| Changement de langue | Une adresse par langue | Objet, contenu et destination du lien dans la même langue |
| Lecture sur mobile | Adresse D | Code, boutons et contenu entièrement visibles |
2. Exécutez d’abord un cas de référence sans interférence
Commencez par une session vierge, sans connexion ni saisie automatique. Après l’envoi de l’inscription, notez le retour affiché et l’heure du déclenchement ; ne changez pas immédiatement d’adresse et ne modifiez pas les informations du compte avant l’arrivée de l’e-mail. À sa réception, vérifiez l’expéditeur, l’objet, le destinataire, le nom de la marque, le format du code et les indications de validité.
À l’ouverture du lien de confirmation, vérifiez le domaine cible et HTTPS, puis revenez à la page d’origine pour confirmer que l’état est synchronisé. Ouvrez ensuite le même lien une seconde fois : un lien idempotent doit conserver l’état confirmé, tandis qu’un lien à usage unique doit afficher clairement qu’il a déjà été utilisé, et non une vague erreur serveur. Une fois le cas de référence validé, lancez les parcours perturbateurs comme les renvois et les expirations.
« L’e-mail s’ouvre » ne suffit pas. Sur un écran étroit, le code ne doit pas être coupé, le texte du bouton ne doit pas déborder, les explications sur fond sombre doivent rester lisibles et la version texte doit conserver les adresses utiles pour les actions importantes.
3. Testez le renvoi des codes comme une machine à états
Après le premier envoi, ne cliquez pas plusieurs fois d’affilée. Vérifiez d’abord que le bouton passe en délai d’attente de 60 secondes ou dans l’état prévu par le produit, puis déclenchez le second envoi à la fin du compte à rebours. Notez l’ordre d’arrivée des deux e-mails, leurs codes et leur durée de validité, puis soumettez successivement l’ancien et le nouveau code.
La règle côté serveur doit être explicitement documentée. Si la génération d’un nouveau code invalide immédiatement l’ancien, celui-ci doit produire une erreur précise ; si les deux codes peuvent coexister brièvement, calculez séparément leur échéance. La page ne doit pas compter uniquement sur la désactivation du bouton : un rafraîchissement ou un autre onglet peut relancer la requête. Le contrôle de la concurrence doit être garanti par les règles côté serveur.
- Dans un même onglet, plusieurs clics pendant le délai d’attente ne doivent-ils créer qu’une seule tâche ?
- Après un rafraîchissement, le délai d’attente est-il toujours appliqué ?
- Deux onglets cliqués simultanément créent-ils plusieurs codes valides impossibles à expliquer ?
- Lorsque les e-mails arrivent dans le désordre, l’interface indique-t-elle clairement lequel utiliser ?
- Une procédure de récupération existe-t-elle après atteinte du nombre maximal d’erreurs ?
4. Testez l’expiration des codes et des liens de part et d’autre de la limite
N’attendez pas qu’ils soient « manifestement expirés » pour cliquer. Effectuez une vérification une minute avant l’échéance, puis une autre peu après, afin de confirmer la cohérence entre la limite temporelle et le texte affiché. L’heure de l’appareil de test ne doit pas déterminer l’acceptation du code par le serveur ; si le code reste accepté après modification de l’horloge locale, la validation est probablement effectuée au mauvais endroit.
La page d’expiration doit expliquer la suite : où revenir, si un renvoi est possible et s’il faut saisir à nouveau l’adresse e-mail. Si un renvoi génère un nouveau lien, l’ancien doit être invalidé selon la stratégie définie. La boîte de réception jetable a elle aussi une durée d’utilisation ; avant une longue attente, prolongez-la pour éviter de confondre l’expiration de la boîte de test avec celle du lien produit.
Journal des tests aux limites
- Durée de validité publiée ou convenue côté serveur ;
- Dernier instant où l’action réussit avant l’échéance ;
- Premier instant où l’action échoue après l’échéance ;
- Type d’erreur de la page d’échec et point d’accès à la récupération ;
- Après un renvoi, l’ancien lien peut-il encore être utilisé ?
5. Les tests multilingues ne se limitent pas au contenu traduit
Créez une adresse distincte pour chaque langue et changez la langue du produit avant le déclenchement. Vérifiez que l’objet, le pré-en-tête, le contenu, les boutons et le pied de page proviennent du même pack linguistique ; n’acceptez pas un résultat hybride avec un objet en anglais et un contenu en chinois. Les formats de date, de fuseau horaire et de nombres doivent également respecter les usages de la langue cible.
Les liens doivent conserver leur contexte linguistique. Un bouton de confirmation dans un e-mail chinois ne doit pas ouvrir une page d’erreur en anglais, et le message affiché après un renvoi ne doit pas revenir à la langue par défaut. Vérifiez les boutons longs en français ou en portugais sur les largeurs mobiles courantes ; en japonais, surveillez les espaces et les retours à la ligne artificiels. Le contenu de secours en texte brut ne doit pas être négligé sous prétexte que le modèle HTML fonctionne.
6. Produisez des résultats exploitables pour la prochaine régression
Un bon compte rendu n’est pas une collection de captures d’écran, mais une procédure réexécutable. Chaque ligne doit inclure l’état initial, le numéro de l’adresse, l’action déclenchée, le résultat attendu, le résultat réel, quatre horodatages clés et un lien vers les preuves. Après un échec, la nouvelle vérification doit utiliser une nouvelle adresse, sauf si vous testez précisément la récupération de cette même identité.
Une fois terminé, nettoyez les données de test et retirez les adresses temporaires de tous les paramètres de récupération de comptes à long terme. L’avantage d’une adresse jetable est de délimiter clairement la tâche ; si vous en dépendez encore pour récupérer un compte après le test, votre stratégie d’identité s’est éloignée de son objectif initial.
Créez une identité indépendante des anciens e-mails
Copiez l’adresse, déclenchez l’inscription et actualisez la boîte de réception ; utilisez le premier résultat comme référence pour les parcours anormaux suivants.