Isoler les identités
Utilisez une nouvelle adresse à chaque cycle de test pour éviter toute interférence d’anciens e-mails, codes ou états de lecture.
Laboratoire e-mail avant mise en production
Checklist de test e-mail pour le développement et la QA
Attribuez une adresse distincte à chaque cas, déclenchez un envoi réel, puis consignez les résultats selon quatre critères : délai de réception, langue du modèle, code de vérification et lien cible.
Établir une base reproductible
Définissez les critères de réussite avant de cliquer sur Envoyer
Un e-mail qui semble être arrivé ne suffit pas pour valider un test. L’équipe doit définir le délai maximal, la durée de validité du code, l’environnement des liens, la langue du modèle et l’affichage mobile afin d’identifier précisément tout écart.
Déclencher le parcours
Effectuez l’action métier via l’interface réelle ou l’API, sans contourner la file d’attente pour appeler directement le service e-mail.
Vérifier le contenu
Contrôlez l’expéditeur, l’objet, les variables, la version texte, les liens des boutons et la localisation.
Conserver les preuves
Notez l’heure de l’événement, l’identifiant du message, les captures d’écran et l’environnement pour faciliter la régression des anomalies.
Matrice de test principale
Couvrez les scénarios de réussite, de renvoi, d’expiration et d’erreur
Ne testez pas uniquement le premier succès. L’identité e-mail dépend souvent de la limitation de débit, de la machine à états et des règles de sécurité ; les cas limites révèlent plus facilement les doublons ou les mauvais modèles.
| Parcours | Cas minimum | Vérification du contenu | Vérification de l’état |
|---|---|---|---|
| Confirmation d’inscription | Premier essai, e-mail déjà utilisé, lien expiré | Formule d’appel, bouton de confirmation, domaine de l’environnement | Utilisation unique, message d’expiration |
| Code de connexion | Correct, incorrect, renvoi, limitation de débit | Code à 6 chiffres, durée de validité, indication de l’appareil | Ancien code invalidé, compte à rebours avant nouvel essai |
| Réinitialisation du mot de passe | Compte existant et compte inexistant | Formulation de sécurité, lien de réinitialisation | Protection contre l’énumération des comptes, révocation du lien |
| Notification de workflow | Réussite, échec, réussite partielle | Nom de la tâche, chiffres, environnement cible | Déduplication, nouvelle tentative, délai |
Affichage et accessibilité
Tester le contenu ne se limite pas à une capture de bureau
Retour à la ligne sur petit écran
À une largeur de 320 à 390 px, vérifiez les objets longs, le texte des boutons, le bloc du code et les URL ; aucune information essentielle ne doit être tronquée horizontalement.
Version texte
Désactivez les images ou affichez la version text/plain pour vérifier que le code, les liens et les informations d’assistance restent complets et compréhensibles.
Langue et sens d’écriture
Faites correspondre la langue du compte à celle du modèle et vérifiez que les dates, la ponctuation et les variables n’utilisent pas encore l’anglais par défaut.
Champs du rapport d’anomalie
Ouvrir le diagnostic de réceptionPermettez au prochain ingénieur de reproduire le problème
Les problèmes d’e-mail traversent l’application métier, la file d’attente, le fournisseur et le système de réception. Sans horodatage ni identifiant unique, l’équipe ne peut que formuler des hypothèses.
Identité de testAdresse e-mail complète, langue du compte, environnement et numéro du cas de test.
Preuves temporellesHeure de l’action, mise en file de la tâche, réception par le fournisseur et arrivée finale.
Preuves du messagemessage ID, version du modèle, objet et variables clés ; n’enregistrez aucun mot de passe réel.
Attendu et constatéPrécisez quel critère de réussite n’a pas été respecté au lieu d’écrire simplement « l’e-mail est incorrect ».