Menu

Test de validation des e-mails: comment tester les fonctionnalités de messagerie d'une application

  • Principal
  • Test Web
  • Test de validation des e-mails: comment tester les fonctionnalités de messagerie d'une application

email validation testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

Le didacticiel d’aujourd’hui consiste à tester les fonctionnalités de messagerie de toute application.

Dans la plupart des applications Web et mobiles, la validation de la fonctionnalité de courrier électronique est considérée comme l'une des parties les plus importantes du test, pour assurer la qualité du composant de courrier électronique ainsi que d'autres composants du système.

Les e-mails déclenchés dans différents scénarios sont considérés comme validés en vérifiant tous ses composants qui incluent un modèle d'e-mail, des liens / boutons dans les champs E-mail, De, À, Cc, Cci, Pièces jointes, Contenu selon la notification par e-mail, etc.

Validation des e-mails

Ce que vous apprendrez:

Pourquoi avons-nous besoin de tests de messagerie?

Chaque composant du système (applications Web / mobiles) peut avoir des objectifs différents pour envoyer des e-mails. Intégration entre le (s) composant (s) et le courrier électronique joue un rôle essentiel pour atteindre l'utilisateur final avec des notifications appropriées. Toute négligence lors de la validation de cette fonctionnalité entraînera des malentendus, une mauvaise réputation des clients, du piratage, etc.

Par exemple , imaginez une situation où un utilisateur a reçu un e-mail pour réinitialiser le mot de passe. Que faire si le lien / bouton Réinitialiser le mot de passe ou l'URL fournie pour copier-coller dans un navigateur ne fonctionne pas? La seule option qui reste ici est de contacter le service client, ce qui peut devenir fastidieux ou imaginer une situation où l'utilisateur continue de recevoir un e-mail quotidiennement concernant la date d'échéance du paiement de la facture de 10 à 15 jours plus tôt ou reçoit un rappel après la date d'échéance. passé. - Irritant n'est-ce pas ??

Il existe de nombreux scénarios dans lesquels les e-mails font désormais partie intégrante de notre vie car ils sont destinés à maintenir l'utilisateur à jour avec des informations précises.

Scénarios en temps réel et points de validation courants pour les e-mails

Les points de validation dans le test des e-mails varient d'un type à l'autre, et encore d'une application à l'autre. Généralement, tous les e-mails doivent être validés pour le modèle (qui comprend le logo de l'application, le nom de l'application, l'adressage de l'utilisateur, le contenu du pied de page - Copyright, les détails du support client), la date et l'horodatage pour différents fuseaux horaires.

Ici, nous allons discuter de certains types courants d'e-mails que presque tout le monde connaît (tous les points de validation donnés ci-dessous sont la vérification de base que le testeur doit effectuer lors du test des e-mails de l'application).

# 1) E-mails d'activation

Lorsqu'un utilisateur s'inscrit à une application pour la première fois, il doit activer le compte en cliquant sur le lien d'activation envoyé dans Email. Cela vérifie également que l'adresse e-mail donnée par l'utilisateur est valide et accessible.

Les points de validation sont les suivants:

  • Lien d'activation ou bouton - Cliquer dessus devrait:
    • Diriger l'utilisateur vers la page de l'application respective avec un compte utilisateur connecté
    • Le compte de messagerie de l'utilisateur doit être vérifié automatiquement si la page de candidature est atteinte avec succès par e-mail
  • Durée - Vérifiez la durée pendant laquelle le lien doit être cliqué et vérifié.
    • Vérifier dans la durée spécifiée
    • Essayez de vérifier une fois la durée écoulée - Le compte ne doit pas être activé et l'e-mail doit rester non vérifié

E-mail d

# 2) Mot de passe oublié

Lorsqu'un utilisateur oublie le mot de passe pour se connecter à l'application, un flux de mot de passe oublié peut être effectué pour recevoir un e-mail avec un lien pour réinitialiser le mot de passe (la fonctionnalité varie d'une application à l'autre. C'est la règle générale).

Les points de validation sont les suivants:

  • Réinitialiser le lien du mot de passe:
    • En cliquant dessus, l'utilisateur doit accéder à la page de l'application respective pour réinitialiser le mot de passe
    • Certaines applications demanderont à l'utilisateur de répondre à une question de sécurité avant d'afficher la page de réinitialisation du mot de passe, et certaines auront une question de sécurité intégrée à la page de réinitialisation du mot de passe elle-même, et certaines n'auront pas du tout cette fonctionnalité
    • Si l'utilisateur réinitialise le mot de passe avec succès, le lien dans l'e-mail de mot de passe oublié qui a été reçu devrait être désactivé et non fonctionnel
    • Si l'utilisateur annule le flux de réinitialisation du mot de passe, le lien dans l'e-mail de mot de passe oublié qui a été reçu doit rester activé
  • Durée - Vérifiez la durée pendant laquelle le lien doit être cliqué pour réinitialiser le mot de passe
    • Cliquez sur le lien et réinitialisez le mot de passe avec succès dans la durée spécifiée
    • Essayez de cliquer sur le lien une fois la durée écoulée - Le lien doit être désactivé et expiré

Réinitialiser l

quelle est la qualité d'ubuntu par rapport à Windows

# 3) Notifications de date d'échéance

Il s'agit de rappeler à l'utilisateur l'action à entreprendre dans un certain nombre de jours. Il s'agit généralement du paiement de la facture, de l'action sur les éléments en attente (exemple: accepter ou refuser l'invitation à un événement dans un nombre de jours donné, soumettre des formulaires, etc.).

Les points de validation sont les suivants:

  • Nombre de jours d'échéance / date d'échéance
    • Si l'e-mail informe d'un certain nombre de jours d'échéance, le nombre doit être égal ou supérieur à zéro, zéro jour étant la date actuelle d'échéance. Il ne devrait pas être en nombres négatifs. Si l'e-mail notifie une date d'échéance (date du calendrier), la date doit être la date actuelle ou future.
  • Type d'action
    • Vérifiez quel est le type d'action requis. Il doit indiquer très clairement le type d'action que l'utilisateur doit entreprendre. Que ce soit le paiement de la facture, les soumissions, les commentaires, etc.

E-mail de date d

Notification par e-mail de la date d

# 4) Notifications en retard

Ceci est pour informer l'utilisateur que la date d'échéance est dépassée. Il s'agit généralement d'informer l'utilisateur qu'il / elle n'a pas pris de mesures sur les éléments dans les délais.

  • Nombre de jours en retard
    • Vérifiez que le nombre de jours en retard doit être un ou plusieurs. Cela ne devrait jamais être zéro ou des nombres négatifs
  • La fréquence
    • Peu d'applications auront la possibilité de personnaliser les e-mails en retard à envoyer quotidiennement / hebdomadairement / mensuellement, une fois la date d'échéance passée, jusqu'à ce que l'utilisateur termine l'action. Peu de candidatures auront la notification standard à envoyer une seule fois seulement après la date d'échéance.

# 5) Abonnements

Cela varie selon les besoins des utilisateurs. L'utilisateur peut sélectionner l'un des abonnements quotidiens, hebdomadaires, bimensuels ou mensuels suivants. Ce sera généralement pour les newsletters, les mises à jour, les offres, etc.

  • La fréquence
    • Les e-mails doivent être envoyés selon la sélection de l'utilisateur pour un abonnement. S'il est quotidien, l'e-mail d'abonnement ne doit être envoyé qu'une fois par jour. Si hebdomadaire, puis une fois par semaine. Et continue…
  • Liens
    • Tous les liens contenus dans l'e-mail doivent accéder à la page respective de l'application. Si l'e-mail concerne des mises à jour, le lien doit rediriger vers la page sur laquelle les mises à jour sont censées être affichées. Si l'e-mail concerne des offres, le lien doit rediriger vers la page Offres de l'application. Cela dépend du type d'abonnement que l'utilisateur a sélectionné.

Email d

Écran d

# 6) Formulaires

Les e-mails ici permettent à l'utilisateur de fournir des commentaires via des formulaires / des liens vers des formulaires. Les points de validation sont les suivants:

  • Liens
    • Le lien dans l'e-mail doit rediriger l'utilisateur vers la page de soumission de formulaire de la demande en fonction du type de formulaire que l'utilisateur doit soumettre
    • Une fois soumis, cliquer à nouveau sur le lien devrait informer l'utilisateur que le formulaire a déjà été soumis. Il ne doit pas permettre à l'utilisateur de soumettre à nouveau le formulaire

Courriel d

Page de sondage

# 7) E-mails de confirmation

Les e-mails sont ici pour informer l'utilisateur de la confirmation de l'action entreprise. Il s'agit généralement des confirmations de réservation, des confirmations de commande, des confirmations de requête, etc.

Les points de validation sont les suivants:

  • Détails de la confirmation:
    • Le numéro de commande / numéro de réservation doit être correct et correspondre au numéro affiché dans l'interface utilisateur de l'application. Comme c'est l'identifiant pour suivre les commandes / réservations, il doit être unique (à valider en backend - DB) dans toute l'application. Aucune commande / réservation ne doit partager le même identifiant.
    • Outre le numéro, il doit également être validé pour le type de commande, les informations utilisateur, l'adresse de facturation, l'adresse de livraison et le prix. Toutes les informations doivent être exactement similaires à celles fournies par l'utilisateur dans l'interface utilisateur de l'application.
  • Liens:
    • Un lien dans l'e-mail doit rediriger un utilisateur vers la page des détails de la commande dans l'interface utilisateur de l'application. Il doit y avoir une correspondance exacte entre les informations dans l'e-mail et l'interface utilisateur de l'application

Email de confirmation

# 8) Transcription du chat

Ici, un utilisateur reçoit l'intégralité de la transcription du chat par e-mail. Cela se produit généralement une fois que le chat en direct avec le support client est terminé.

Les points de validation sont comme ci-dessous

  • Des détails
    • Vérifiez le nom de la personne qui a fourni l'assistance en ligne. Vérifiez que l'intégralité du chat est présent dans l'e-mail avec les détails de l'expéditeur pour chaque entrée de chat (nom de la personne, date et heure d'envoi du message de chat, etc.)

# 9) E-mails avec pièce jointe

L'utilisateur reçoit des e-mails avec pièce jointe. Les pièces jointes peuvent être protégées par mot de passe / non protégées. Il s'agit généralement des déclarations des domaines financiers, du contrat de licence de l'utilisateur final pour référence, des termes et conditions pour référence, etc., cela varie encore d'une application à l'autre.

Les points de validation sont les suivants:

  • Type de pièce jointe
    • Les types de fichiers valides doivent être envoyés en pièce jointe. Toutes les pièces jointes ouvertes doivent être analysées contre les virus avant le téléchargement / l'ouverture. Cela peut à nouveau être personnalisé au niveau de l'application au niveau du backend, comme une analyse antivirus à effectuer uniquement lors du téléchargement, uniquement lors de l'ouverture, pour le téléchargement et l'ouverture.
    • Les pièces jointes protégées par mot de passe doivent être téléchargées sans demander le mot de passe. Mais lors de son ouverture à partir du courrier électronique lui-même ou de l'ouverture de la copie téléchargée, vous devez toujours demander le mot de passe. Les entrées de mot de passe incorrectes ici seront indéfinies car la copie locale ne peut pas être suivie en ligne pour verrouiller la pièce jointe

Email avec pièce jointe

Pièce jointe protégée par mot de passe

Types d'e-mails

Le type d'e-mail peut être soit HTML (coloré et attrayant pour les utilisateurs, ce qui intéresse l'utilisateur à lire entièrement les e-mails) ou Texte brut (juste un texte).

HTML est le plus préféré et généralement défini par défaut dans presque toutes les applications du backend. Si nécessaire, les applications peuvent choisir d'envoyer des e-mails en texte brut aux utilisateurs, encore une fois, cela nécessite des modifications au niveau du backend.

avec quoi puis-je ouvrir un fichier eps

Points de déclenchement des e-mails:

Les e-mails peuvent être envoyés immédiatement ou sous forme de résumé / lot. Les e-mails immédiats sont déclenchés par l'action de l'utilisateur. Il s’agit généralement d’e-mails d’activation, d’e-mails de réinitialisation de mot de passe, de transcriptions de chat, d’e-mails de confirmation, etc.

Les points de déclenchement des e-mails seront définis pour se déclencher à un moment précis ( par exemple 3rdjour de chaque semaine à 12h00). Il s'agira généralement des relevés des domaines financiers (relevés bancaires), de la notification de la date d'échéance des factures, des notifications en retard, des abonnements, etc.,

Rebonds:

C'est un scénario très courant où les e-mails rebondissent lorsqu'ils sont envoyés à une adresse e-mail invalide. Habituellement, l'adresse e-mail qui est désactivée / n'est plus utilisée et n'existe pas du tout - sont les candidats qui rebondissent.

Le serveur essaie généralement un certain nombre de fois d'envoyer un e-mail à l'adresse prévue. Lorsqu'il n'atteint pas l'adresse e-mail prévue, il est renvoyé et fera une entrée dans le serveur pour son échec. Il y aura un serveur différent pour maintenir ce type d'activités et sont généralement appelés serveurs de rebond. Il peut y avoir plusieurs raisons pour qu'un e-mail échoue en atteignant son utilisateur.

Voici quelques autres points d'échec:

  • Le serveur de messagerie est en panne depuis longtemps
  • L'algorithme pour trouver un itinéraire court pour atteindre l'utilisateur ne fonctionne pas correctement et prend très longtemps pour atteindre l'utilisateur, à ce moment-là peut-être qu'il aurait dépassé le temps spécifié pour atteindre l'utilisateur. Ceci est généralement appelé augmentation du nombre de sauts
  • Le domaine de messagerie de l'utilisateur est en panne depuis longtemps
  • Le compte de l'utilisateur pour l'application n'est pas activé pour recevoir des e-mails

Portée de la localisation pour les tests des e-mails

Lorsque l'application prend en charge plusieurs langues, la prise en charge doit également s'étendre aux e-mails.

Tous les e-mails envoyés doivent être dans la langue du profil utilisateur. Si un utilisateur a défini l'anglais comme langue de profil, tous les e-mails qui lui sont envoyés doivent être en anglais. Si la langue du profil de l'utilisateur est le français, tous les e-mails qui lui sont envoyés doivent être en français. La langue du profil utilisateur peut être des paramètres uniques ou peut être modifiée au besoin, en fonction des paramètres de l'application.

Questions et réponses d'entrevue informatica administrateur

L'e-mail doit être envoyé dans la langue de l'utilisateur au moment où il est déclenché.

Les points de validation courants pour les tests de localisation des e-mails sont les suivants:

  • Ligne d'objet
  • Corps de l'e-mail
    • Contenu - texte du corps
    • Nom du lien / nom du bouton
    • Informations sur le droit d'auteur
    • Détails du support client

Standard / Personnalisation des e-mails

Les e-mails peuvent être personnalisés au niveau du backend.

Par exemple , peu d'applications prennent en charge l'utilisateur pour personnaliser les e-mails lorsqu'ils sont envoyés. L'utilisateur peut modifier ici la ligne d'objet et / ou le corps de l'e-mail à sa convenance ou dans le but de le reconnaître facilement. Dans ce cas, des tests approfondis doivent être effectués par l'équipe de test car les chances d'intrusion sont élevées.

Des tests doivent être effectués pour les injections - envoyer du code HTML, du code Java, SQL, etc. Tout cela devrait échouer afin d'augmenter les niveaux de sécurité. Si l'application ne prend pas en charge la personnalisation des e-mails, tous les e-mails envoyés suivront le sujet / corps standard défini par une application.

Conclusion

Le test des e-mails est une activité importante car la plupart des composants de l'application sont intégrés à cette fonctionnalité.

Ce devrait être le soutien et les efforts de toute l’équipe pour tester complètement la fonctionnalité de messagerie de l’application. Cela devrait être bien planifié bien avant le début des tests et devrait aller de pair lors du test de chaque composant / composant associé.

Email Testing devrait avoir des cas de test séparés pour chaque type d'e-mail couvrant tous les aspects à tester. Cela doit être effectué dans tous les types de tests Tests de régression, tests ad hoc, tests de localisation, tests UAT et tests de production.

Tout ce qui ne va pas dans le courrier électronique en temps réel laissera une mauvaise impression sur l'application, les clients et éventuellement, il sera transmis aux testeurs de cette application. Les validations par e-mail sont donc une activité très cruciale et indispensable dans les tests de logiciels.

A propos de l'auteur: Cet article est écrit par l'auteur de STH Nandini K. Elle a plus de 7 ans d'expérience dans les tests de logiciels, principalement dans les tests d'applications Web.

Faites-nous savoir si vous avez des questions / suggestions.

lecture recommandée

^