Checklist pour le développement et l’assurance qualité
Recevoir un e-mail ne suffit pas. Cette checklist vérifie à la fois le déclenchement métier, l’identité du destinataire, la structure du contenu, les points d’action, les délais, les échecs et les limites de confidentialité, afin de rendre la validation reproductible.
Périmètre
Ces cartes ne sont pas décoratives. Suivez l’ordre des tests de gauche à droite ; l’échec d’un point bloquant ne doit jamais être validé par un simple « renvoyer ».
Avant le test, précisez qui effectue quelle action et dans quel état, puis listez les conditions qui doivent ou non déclencher un envoi. Tester uniquement le succès fait passer à côté de branches importantes : préférences de notification désactivées, compte déjà vérifié ou déduplication d’un événement répété.
Copiez l’adresse de réception depuis la barre d’outils de test actuelle pour éviter toute saisie manuelle. Après un changement d’adresse, mettez à jour l’utilisateur de test : les anciens messages ne sont pas transférés et mélanger les adresses fausse les résultats.
Vérifiez la longueur du code, son jeu de caractères, sa durée de validité, son invalidation après usage unique et les règles de renvoi. Si la page annonce 10 minutes alors que le backend expire le code après 5 minutes, il s’agit d’un défaut fonctionnel, pas d’un simple problème de texte.
Vérifiez aussi les retours pour code incorrect ou expiré, les saisies répétées et les renvois trop fréquents. Pour les validations par lien, contrôlez le protocole, le nom d’hôte, l’environnement, le jeton à usage unique et la page finale après redirection ; ne vous contentez pas de vérifier que le bouton fonctionne.
Dans le corps du message, contrôlez la largeur du conteneur, les retours à la ligne des titres, la hauteur des boutons, l’espacement des paragraphes et le redimensionnement des images. Les noms longs, noms de projet longs et boutons en français ou en portugais font plus facilement déborder la mise en page que le chinois : effectuez la régression avec l’échantillon raisonnable le plus long.
Même images désactivées, la marque et l’action principale doivent rester identifiables ; la version en texte brut doit conserver le code, la durée, les liens et les informations d’assistance. Ne placez pas tout le contenu dans une image et ne laissez pas le texte d’aperçu masqué apparaître en première ligne du message.
Ouvrez un à un le bouton principal, les liens secondaires, l’accès à l’aide et le lien de désabonnement. Vérifiez le domaine cible, le chemin, les paramètres et l’état de connexion. Les liens de test ne doivent pas pointer par erreur vers des opérations d’écriture en production, et les modèles de production ne doivent pas contenir de domaine de test.
Pour les pièces jointes, vérifiez le nom, le type, la taille et les autorisations ; les types dangereux doivent être bloqués ou isolés. Lors d’une réponse, contrôlez que Reply-To arrive bien au canal d’assistance prévu et non à une adresse d’envoi non surveillée.
L’objet, l’aperçu, le corps, les boutons et les messages d’erreur doivent utiliser la même langue ; les dates, montants et fuseaux horaires doivent respecter le format de la région de l’utilisateur. En cas de traduction manquante, appliquez un repli maîtrisé plutôt que de mélanger les langues au hasard dans un même e-mail.
La hiérarchie des titres doit être continue et le texte des liens doit décrire leur destination ; les images doivent avoir un texte alternatif adapté. La couleur ne doit pas être l’unique moyen d’indiquer un état, et le contraste doit rester suffisant pour un texte clair sur fond blanc comme pour un texte sombre sur fond coloré.
Simulez un retard de file d’attente, un refus temporaire du prestataire et un rebond définitif. Vérifiez que le système réessaie selon la stratégie prévue sans envoyer de notifications en double. L’interface doit fournir un état exploitable, plutôt que de qualifier tous les échecs d’« erreur réseau ».
Si l’e-mail de test n’arrive pas, diagnostiquez progressivement les preuves côté application, file d’attente, plateforme d’envoi, DNS et réception. Conservez les preuves du premier échec avant de vérifier la correction ; ne supprimez pas les indices initiaux parce qu’un renvoi a finalement réussi.
| Niveau | Exemple | Critère de mise en production | Traitement de l’échec |
|---|---|---|---|
| Bloquant | E-mail non généré, mauvais destinataire, code inutilisable, lien principal incorrect | Tout doit être validé | Arrêter la mise en production et corriger la cause racine |
| Élevé | Envois en double, durée incohérente, corps tronqué sur mobile | À corriger ou à accepter par écrit par le responsable | Définir une échéance claire et un cas de régression |
| Moyen | Aperçu redondant, libellé de lien secondaire imprécis, mauvaise coupure des textes longs | Évaluer l’audience et la fréquence | Planifier dans la prochaine itération et conserver les preuves |
| Faible | Légère différence visuelle sans impact sur la tâche | Ne bloque pas le parcours principal | Consigner le modèle et le périmètre des clients |
Consignez le numéro du cas, l’environnement, la version du modèle, la langue, le préfixe de l’adresse de réception, les heures de déclenchement et de réception, l’ID du message, le résultat et le lien vers le défaut. Les captures doivent couvrir l’objet et le corps essentiel, tout en masquant les jetons et les données personnelles réelles.
Après correction, effectuez une régression dans les mêmes conditions et testez aussi le parcours d’échec le plus proche. Pour vous aider à localiser un problème de délivrabilité, consultez le guide de diagnostic de délivrabilité ou contactez support@msgtmp.com.
