Les tests manuels d'e‑mail deviennent lents lorsque les testeurs réutilisent une boîte de réception remplie de vieux messages et cliquent à plusieurs reprises sur renvoyer sans enregistrer ce qui s'est passé. Un peu de structure rend la prochaine reproduction plus facile à interpréter.
Préparer un contexte de test
Enregistrez la version de l'application, l'environnement, le compte synthétique et le destinataire. Notez quels messages vous attendez et quel état de l'application doit changer. Excluez les messages non pertinents du résultat en utilisant une nouvelle adresse de test lorsqu'elle est prise en charge.
Exécuter le flux une fois
- Enregistrez l'heure de l'action déclenchante.
- Observez la confirmation ou l'erreur de l'application.
- Attendez dans une fenêtre de test convenue sans demander de nouveau mail de façon répétée.
- Ouvrez le message correspondant et vérifiez son texte, ses liens de destination et le résultat.
- Capturez une description assainie de toute différence par rapport à l'attente.
Modifier une variable
Si le test échoue, décidez ce que la prochaine tentative doit isoler. Modifier simultanément le navigateur, l'adresse, la version de l'application et le timing du renvoi rend une réussite ultérieure difficile à expliquer. Conservez un résultat séparé pour chaque tentative.
Rédiger un rapport de bug utile
Incluez le comportement attendu, le comportement observé, les horodatages et une séquence reproductible. Étiquetez l'absence de livraison séparément du rendu défectueux ou d'un lien invalide. Masquez les jetons de vérification en direct et les adresses personnelles sur les captures d'écran.
Pour les investigations de longue durée, utilisez une boîte aux lettres de test maintenue. Le nettoyage temporaire de la boîte de réception peut autrement supprimer les preuves entre le rapport initial et la révision du développeur. Exportez uniquement les preuves non sensibles que votre équipe est autorisée à conserver.