Checklist QA : tester une inscription + OTP avec un e-mail jetable

Les parcours d’inscription avec OTP (One-Time Password) ou lien magique par e-mail semblent simples… jusqu’au moment où vous testez avec une adresse jetable. Entre les délais de délivrabilité, les filtres anti-abus, les “resend” qui s’empilent et les expirations côté serveur, un test peut devenir non reproductible, voire trompeur.

Cette checklist est pensée pour les équipes QA, produit et dev qui veulent valider un signup + OTP de façon fiable, y compris avec des e-mails temporaires / jetables. L’objectif : couvrir les cas normaux, les cas limites, et obtenir des signaux clairs (logs, métriques, traces) quand quelque chose casse.

1) Pré-requis de test (avant même de cliquer sur “S’inscrire”)

1.1 Choisir le bon type d’e-mail jetable selon le scénario

• OTP unique immédiat : une boîte “courte durée” peut suffire si votre délivrabilité est rapide.
• Double opt-in / multi-e-mails : privilégier une boîte jetable plus flexible, ou un service qui conserve l’adresse plus longtemps.
• Tests répétitifs (même domaine / même IP) : prévoyez plusieurs adresses et une rotation pour éviter les blocages anti-abus.

1.2 Préparer une matrice d’environnements

• Staging (avec SMTP sandbox) vs Préprod vs Prod (si autorisé).
• Configuration DMARC/DKIM/SPF cohérente sur l’environnement ciblé.
• Feature flags : OTP par e-mail, lien magique, CAPTCHA, rate-limit, blocage domaines jetables.

1.3 Définir des critères d’acceptation mesurables

• Temps de réception moyen (et max acceptable) du message OTP.
• Validité du code (TTL) côté serveur, et comportement après expiration.
• Comportement “Resend” : limites, cooldown, invalidation des anciens codes.
• Messages d’erreur : clairs, localisés, sans fuite d’information sensible.

2) Parcours nominal : inscription + OTP (happy path)

2.1 Création de compte (écran signup)

• Validation front : format e-mail, champs obligatoires, contraintes de mot de passe (si applicable).
• Validation back : normalisation de l’e-mail (casse, espaces), refus si déjà existant.
• Vérifier l’accessibilité : focus, labels, feedback d’erreurs lisibles.

2.2 Envoi de l’OTP

• Le backend génère un OTP (format attendu, longueur, entropie suffisante).
• Le message e-mail contient uniquement ce qui est nécessaire : code ou lien, durée de validité, support.
• Vérifier l’absence d’informations à risque : pas de données perso inutiles, pas de token en clair réutilisable.

2.3 Réception et saisie du code

• Le code reçu est utilisable une seule fois (single-use).
• La saisie accepte copier-coller, gère les espaces, et se comporte bien sur mobile.
• Le succès redirige vers l’étape attendue (dashboard, onboarding, etc.).

3) OTP : cas limites indispensables

3.1 Code expiré

• Attendre l’expiration côté serveur puis tenter la validation.
• Attendu : message “code expiré”, bouton pour renvoyer, et aucun état “semi-connecté”.
• Vérifier la cohérence : le front ne doit pas mentir sur la durée réelle.

3.2 Mauvais code

• Tester une suite de mauvais codes (y compris même longueur) pour valider le comportement.
• Attendu : compteur de tentatives, blocage progressif ou cooldown si prévu.
• Le message d’erreur ne doit pas révéler si l’e-mail est valide/existant (anti-enum).

3.3 Réutilisation d’un code déjà consommé

• Valider une première fois, puis réessayer le même OTP.
• Attendu : refus net, et logs indiquant “otp_already_used”.

3.4 Resend : ancien code invalide ou non ?

• Cliquer sur “Renvoyer” avant d’utiliser le premier code.
• Décision produit à valider : le nouveau code invalide-t-il le précédent ?
• Attendu : comportement stable et documenté, sinon QA ne peut pas conclure.

3.5 Multiples renvois et synchronisation

• Enchaîner plusieurs “resend” (avec et sans refresh de page).
• Vérifier l’ordre de réception des e-mails : le dernier n’arrive pas toujours en dernier.
• Attendu : seul le code le plus récent (ou le bon selon la règle) doit fonctionner.

4) Délivrabilité et anti-spam : tester ce qui casse “en vrai”

4.1 Délais variables

• Réseau lent, throttling SMTP, et file d’attente : mesurer la latence bout en bout.
• Attendu : UI qui gère l’attente (état “envoi…”, indication de renvoi après un délai).

4.2 Contenu e-mail et score spam

• Sujet trop agressif, trop de liens, mots “promo” : cela peut dégrader la délivrabilité.
• Attendu : un template sobre, lisible, orienté transactionnel.

4.3 Blocage des domaines jetables

• Si la plateforme bloque certains domaines : vérifier le message côté UI (clair, non accusateur).
• Tester aussi le cas “domaine non listé mais jetable” : l’anti-abus ne doit pas casser des e-mails valides.

4.4 Rate limiting et anti-automation

• Tester plusieurs inscriptions rapides depuis la même IP / même device.
• Attendu : CAPTCHA ou throttling progressif, sans bloquer les vrais utilisateurs trop vite.

5) Signup + OTP : scénarios “produit” qu’on oublie souvent

5.1 Double opt-in vs OTP

• Parcours double opt-in : lien de confirmation + éventuellement OTP ensuite.
• Vérifier l’état : compte “pending” tant que non confirmé, puis “active”.
• Attendu : pas de confusion côté UI (éviter les statuts invisibles).

5.2 Changement d’e-mail pendant le parcours

• Entrer un e-mail, demander l’OTP, puis changer d’e-mail avant validation.
• Attendu : l’OTP doit être lié à l’adresse correcte, et l’UI doit clarifier où il a été envoyé.

5.3 Reprise après refresh / fermeture

• Fermer l’onglet, rouvrir, ou refresh l’écran OTP.
• Attendu : l’utilisateur retrouve un état cohérent (session de vérif, possibilité de renvoi, etc.).

5.4 Multi-device / multi-navigateurs

• Lancer l’inscription sur desktop, récupérer l’e-mail sur mobile, saisir l’OTP sur desktop.
• Attendu : pas de dépendance fragile à un stockage local non nécessaire.

6) Sécurité : vérifier sans compliquer l’expérience

6.1 Pas de fuite d’information (anti-enumeration)

• Sur “renvoi OTP” ou “mot de passe oublié”, éviter les messages du type “compte inexistant”.
• Attendu : réponse neutre et comportement identique (temps et contenu) autant que possible.

6.2 Protection contre brute force

• Limiter les tentatives OTP, introduire un cooldown, et journaliser les échecs.
• Tester les erreurs : le système doit rester stable sous mauvaises tentatives répétées.

6.3 TTL, single-use, et stockage sécurisé

• OTP hashé côté serveur (ou équivalent), pas stocké en clair.
• Rotation des secrets si vous utilisez des tokens signés.
• Revocation si un nouvel OTP est émis (selon règle).

7) Observabilité : rendre les tests reproductibles

Les tests OTP échouent souvent “de manière aléatoire” parce que l’équipe ne voit pas où le pipeline a cassé : génération, template, SMTP, réputation, inbox, ou validation. Une bonne observabilité transforme ça en diagnostic rapide.

7.1 Logs côté backend (événements recommandés)

• otp_generated : user_id (ou hash), canal, TTL, contexte (signup, login, reset).
• email_queued : provider, template_id, correlation_id.
• email_sent : id provider, horodatage, succès/échec.
• otp_verified : succès/échec, raison, tentative, ip_hash.
• otp_rate_limited : déclenchement et paramètres.

7.2 Corrélation front ↔ back

• Un request_id affichable en debug (ou accessible via console) aide QA à remonter un incident.
• Vérifier que les erreurs backend remontent un code exploitable (sans exposer de secrets).

8) Checklist finale (copiable en ticket QA)

• Signup : validations front/back OK, états UI cohérents.
• OTP : réception, saisie, succès, redirection OK.
• Erreur OTP : mauvais code, code expiré, code déjà utilisé.
• Resend : cooldown, limites, règle d’invalidation des anciens codes validée.
• Délivrabilité : latence mesurée, template transactionnel, cas “mail arrive tard”.
• Anti-abus : rate limiting, CAPTCHA si applicable, anti-enumeration.
• Reprise : refresh, retour arrière, multi-device.
• Observabilité : logs et correlation_id utilisables pour diagnostiquer un échec.

Conclusion

Tester un parcours d’inscription + OTP avec un e-mail jetable est un excellent “stress test” : si ça passe dans ces conditions, le flux sera souvent solide en production. La clé, c’est de séparer ce qui relève de l’expérience utilisateur (UI, erreurs, resend) de ce qui relève de la délivrabilité (SMTP, contenu, réputation) et de rendre chaque étape observable.

Avec cette checklist, vous pouvez couvrir les scénarios essentiels, éviter les faux positifs (“ça marche chez moi”), et transformer les échecs en diagnostics rapides plutôt qu’en sessions de debug interminables.