email validation testing
De tutorial van vandaag gaat helemaal over het testen van de e-mailfunctionaliteit van elke applicatie.
In de meeste web- en mobiele applicaties wordt het valideren van de e-mailfunctie beschouwd als een van de belangrijkste onderdelen van het testen, om de kwaliteit van de e-mailcomponent en andere componenten van het systeem te waarborgen.
E-mails die onder verschillende scenario's worden geactiveerd, worden als gevalideerd beschouwd door te controleren op al zijn componenten, waaronder een sjabloon met e-mail, koppelingen / knoppen in de velden E-mail, Van, Aan, Cc, Bcc, Bijlagen, Inhoud volgens e-mailmelding, enz.
Wat je leert:
- Waarom hebben we e-mailtesten nodig?
Waarom hebben we e-mailtesten nodig?
Elke component in het systeem (web- / mobiele applicaties) kan verschillende doeleinden hebben om e-mails te verzenden. Integratie tussen de component (en) en e-mail speelt een cruciale rol bij het bereiken van de eindgebruiker met de juiste meldingen. Elke nalatigheid bij het valideren van deze functie zal leiden tot misverstanden, slechte naam bij de klanten, hacking, enz.
Bijvoorbeeld , stel je een situatie voor waarin een gebruiker een e-mail heeft ontvangen om het wachtwoord opnieuw in te stellen. Wat moet ik doen als de link / knop voor het opnieuw instellen van het wachtwoord of de URL voor kopiëren en plakken in een browser niet werkt? De enige optie die hier overblijft is om contact op te nemen met de klantenondersteuning, wat een vervelend iets kan worden of een situatie kan voorstellen waarin de gebruiker dagelijks een e-mail ontvangt met betrekking tot de vervaldatum voor factuurbetaling van 10-15 dagen eerder of een herinnering ontvangt nadat de vervaldatum is geslaagd. - Irriterend is het niet ??
Er zijn veel scenario's waarin e-mails een integraal onderdeel van ons leven zijn geworden, omdat ze bedoeld zijn om de gebruiker op de hoogte te houden van nauwkeurige informatie.
Algemene realtime scenario's en validatiepunten voor e-mails
Validatiepunten bij het testen van e-mails variëren van type tot type en weer van applicatie tot applicatie. Gewoonlijk moeten alle e-mails worden gevalideerd voor de sjabloon (inclusief het toepassingslogo, de naam van de toepassing, het aanspreken van de gebruiker, de inhoud van de voettekst - Copyright, klantondersteuningsdetails), de datum en het tijdstempel voor verschillende tijdzones.
Hier zullen we enkele veelvoorkomende soorten e-mail bespreken waarvan bijna iedereen op de hoogte is (alle onderstaande validatiepunten zijn de basiscontrole die de tester moet uitvoeren tijdens het testen van e-mails van de applicatie).
# 1) Activeringse-mails
Wanneer een gebruiker zich voor de eerste keer bij een applicatie registreert, moet hij / zij het account activeren door op de activeringslink te klikken die in e-mail is verzonden. Dit verifieert ook dat het opgegeven e-mailadres van de gebruiker geldig en toegankelijk is.
Validatiepunten zijn als volgt:
- Activatielink of -knop - Als u erop klikt, moet u:
- Breng de gebruiker naar de pagina van de betreffende app met een aangemeld gebruikersaccount
- Het e-mailaccount van de gebruiker moet automatisch worden geverifieerd als de aanvraagpagina met succes via e-mail wordt bereikt
- Duur - Controleer de duur waarbinnen op de link moet worden geklikt en geverifieerd.
- Controleer binnen de opgegeven duur
- Probeer te verifiëren nadat de duur is verstreken - Account mag niet worden geactiveerd en e-mail mag niet worden geverifieerd
# 2) E-mails met wachtwoord vergeten
Wanneer een gebruiker het wachtwoord vergeet om in te loggen op de applicatie, kan een wachtwoord-stroom worden uitgevoerd om een e-mail te ontvangen met een link om het wachtwoord opnieuw in te stellen (de functie varieert van applicatie tot applicatie. Dit is de algemene).
Validatiepunten zijn als volgt:
- Wachtwoord opnieuw instellen link:
- Als u erop klikt, gaat de gebruiker naar de pagina van de betreffende app om het wachtwoord opnieuw in te stellen
- Sommige toepassingen zullen de gebruiker vragen om een beveiligingsvraag te beantwoorden voordat de pagina voor het opnieuw instellen van het wachtwoord wordt weergegeven, en sommige hebben een beveiligingsvraag geïntegreerd met de pagina voor het opnieuw instellen van het wachtwoord zelf, en sommige hebben deze functie helemaal niet
- Als de gebruiker het wachtwoord met succes heeft gereset, moet de link in de ontvangen e-mail Wachtwoord vergeten worden gedeactiveerd en niet meer werken
- Als de gebruiker de stroom voor het opnieuw instellen van het wachtwoord annuleert, moet de link in de ontvangen e-mail Wachtwoord vergeten geactiveerd blijven
- Duur - Controleer de duur waarbinnen op de link moet worden geklikt om het wachtwoord opnieuw in te stellen
- Klik op de link en reset het wachtwoord met succes binnen de opgegeven duur
- Probeer op de link te klikken nadat de duur is verstreken - de link moet worden gedeactiveerd en verlopen
de beste spraak-naar-tekstsoftware
# 3) Vervaldatummeldingen
Dit is om de gebruiker te herinneren aan de actie die in een bepaald aantal dagen moet worden ondernomen. Dit zijn meestal het betalen van rekeningen, het ondernemen van actie op items die in behandeling zijn (bijvoorbeeld: de uitnodiging voor een evenement binnen een bepaald aantal dagen accepteren of afwijzen, formulieren indienen, enz.).
Validatiepunten zijn als volgt:
- Aantal vervaldagen / vervaldatum
- Als een e-mail bericht over een aantal vervaldagen, moet het aantal nul of meer zijn, nul dagen bedoeld als de huidige datum waarop de vervaldag is. Het mag geen negatieve getallen zijn. Als e-mail melding maakt van een vervaldatum (kalenderdatum), moet de datum de huidige of de toekomstige datum zijn.
- Type actie
- Controleer wat voor soort actie vereist is. Het moet heel duidelijk aangeven wat voor soort actie de gebruiker moet ondernemen. Of het nu gaat om de betaling van de factuur, inzendingen, feedback, enz.
# 4) Achterstallige meldingen
Dit is om de gebruiker te informeren dat de vervaldatum is verstreken. Dit is meestal om de gebruiker te informeren dat hij / zij niet op de vervaldatum actie heeft ondernomen op de items.
- Aantal achterstallige dagen
- Controleer of het aantal achterstallige dagen een of meer moet zijn. Het mogen nooit nul of negatieve getallen zijn
- Frequentie
- Er zijn maar weinig applicaties die de mogelijkheid hebben om achterstallige e-mails aan te passen die dagelijks / wekelijks / maandelijks worden verzonden, zodra de vervaldatum is verstreken, totdat de gebruiker de actie heeft voltooid. Bij weinig aanvragen wordt de standaardmelding slechts één keer verzonden nadat de vervaldatum is verstreken.
# 5) Abonnementen
Dit verschilt per gebruikersvereisten. De gebruiker kan kiezen uit de volgende dagelijkse, wekelijkse, tweemaandelijkse of maandelijkse abonnementen. Dit is meestal voor nieuwsbrieven, updates, aanbiedingen, etc.
- Frequentie
- E-mails moeten worden verzonden volgens gebruikersselectie voor een abonnement. Indien Dagelijks, dan zou de abonnements-e-mail slechts één keer per dag moeten worden verzonden. Indien wekelijks, dan eens per week. En gaat verder ...
- Links
- Alle links in de e-mail moeten naar de respectieve pagina van de applicatie gaan. Als de e-mail voor updates is, moet de link doorverwijzen naar de pagina waar updates moeten worden weergegeven. Als de e-mail voor aanbiedingen is, moet de link doorverwijzen naar de pagina Aanbiedingen van de applicatie. Het hangt af van het type abonnement dat de gebruiker heeft geselecteerd.
# 6) Formulieren
E-mails hier zijn bedoeld om de gebruiker feedback te geven via formulieren / link naar formulieren. Validatiepunten zijn als volgt:
- Links
- De link in de e-mail moet de gebruiker doorverwijzen naar de formulierinzendingspagina van de aanvraag volgens het type formulier dat de gebruiker moet indienen
- Eenmaal ingediend, zou het opnieuw klikken op de link de gebruiker moeten laten weten dat het formulier al is verzonden. Het mag de gebruiker niet toestaan het formulier opnieuw in te dienen
# 7) Bevestigingsmails
E-mails hier zijn bedoeld om de gebruiker op de hoogte te stellen van de bevestiging van de ondernomen actie. Dit zijn meestal de reserveringsbevestigingen, orderbevestigingen, vraagbevestigingen, enz.
Validatiepunten zijn als volgt:
- Bevestigingsdetails:
- Bestelnummer / boekingsnummer moet correct zijn en overeenkomen met het nummer dat wordt weergegeven in de gebruikersinterface van de applicatie. Omdat het de identifier is om de bestellingen / boekingen bij te houden, moet het uniek zijn (te valideren in backend - DB) in de hele applicatie. Geen enkele bestelling / boeking mag dezelfde identificatie hebben.
- Naast het nummer moet het ook worden gevalideerd voor het type bestelling, gebruikersinformatie, factuuradres, verzendadres en prijs. Alle informatie moet exact overeenkomen met wat de gebruiker heeft opgegeven in de gebruikersinterface van de applicatie.
- Links:
- Een link in de e-mail moet een gebruiker naar de detailpagina van de bestelling in de gebruikersinterface van de applicatie leiden. Er moet een exacte overeenkomst zijn tussen de informatie in de e-mail en de gebruikersinterface van de applicatie
# 8) Chat-transcriptie
Hier ontvangt een gebruiker het volledige chattranscript als e-mail. Dit is meestal als de livechat met klantenondersteuning is beëindigd.
Validatiepunten zijn zoals hieronder
- Details
- Controleer de naam van de persoon die online ondersteuning heeft geboden. Controleer of de hele chat aanwezig is in de e-mail met de gegevens van de afzender voor elk chatitem (naam van de persoon, datum en tijd waarop het chatbericht is verzonden, enz.)
# 9) E-mails met bijlage
De gebruiker ontvangt e-mails met bijlage. Bijlagen kunnen met een wachtwoord worden beveiligd / onbeschermd. Dit zijn meestal de verklaringen van financiële domeinen, de licentieovereenkomst voor de eindgebruiker ter referentie, de algemene voorwaarden ter referentie, enz. Dit verschilt weer van applicatie tot applicatie.
sql server 2012 interviewvragen en antwoorden voor ervaren
Validatiepunten zijn als volgt:
- Type bijlage
- Geldige bestandstypen moeten als bijlage worden verzonden. Alle bijlagen die worden geopend, moeten op virussen worden gescand voordat ze worden gedownload / geopend. Dit kan weer worden aangepast op applicatieniveau op de backend, zoals een virusscan die alleen moet worden uitgevoerd tijdens het downloaden, alleen bij het openen, voor zowel downloaden als openen.
- Bijlagen die met een wachtwoord zijn beveiligd, moeten worden gedownload zonder om het wachtwoord te vragen. Maar tijdens het openen vanuit e-mail zelf of tijdens het openen van de gedownloade kopie, moet altijd om het wachtwoord worden gevraagd. Onjuiste wachtwoordinvoer hier is voor onbepaalde tijd omdat de lokale kopie niet online kan worden gevolgd om de bijlage te vergrendelen
Soorten e-mails
Het e-mailtype kan HTML zijn (kleurrijk en aantrekkelijk voor de gebruikers, wat de gebruiker interesseert om de e-mails volledig te lezen) of platte tekst (alleen een tekst).
HTML heeft de meeste voorkeur en wordt meestal als standaard ingesteld in bijna alle applicaties aan de achterkant. Indien nodig kunnen applicaties ervoor kiezen om e-mails in platte tekst naar gebruikers te sturen, ook dit vereist wijzigingen aan de achterkant.
Triggerpunten voor e-mails:
E-mails kunnen direct of als samenvatting / batch worden verzonden. Onmiddellijke e-mails worden geactiveerd door de actie van de gebruiker. Dit zijn meestal activerings-e-mails, e-mails voor het resetten van wachtwoorden, chattranscripties, bevestigings-e-mails, enz., D.w.z. samenvatting / batch-e-mails worden geactiveerd op basis van de instellingen in de backend van de applicatie.
E-mailtriggerpunten worden gedefinieerd om op het specifieke tijdstip ( bijvoorbeeld 3rddag van elke week om 00:00 uur). Dit zijn meestal de afschriften van financiële domeinen (bankafschriften), kennisgeving van vervaldatums voor facturen, achterstallige meldingen, abonnementen, enz.,
Bouncebacks:
Het is een veelvoorkomend scenario dat e-mails bouncen wanneer ze naar een ongeldig e-mailadres worden gestuurd. Meestal zijn het e-mailadres dat is gedeactiveerd / niet meer in gebruik en helemaal niet bestaat, de kandidaten die terugveren.
De server probeert gewoonlijk een bepaald aantal keren e-mail naar het beoogde adres te verzenden. Wanneer het het beoogde e-mailadres niet bereikt, wordt het teruggestuurd en maakt het een vermelding op de server voor het mislukken ervan. Er zal een andere server zijn om dit soort activiteiten te onderhouden en deze worden meestal bounce back-servers genoemd. Er kunnen verschillende redenen zijn waarom een e-mail de gebruiker niet bereikt.
Hieronder staan enkele andere punten voor mislukking:
- E-mailserver is lange tijd uitgeschakeld
- Het algoritme om een korte route te vinden om de gebruiker te bereiken, werkt niet correct en het duurt erg lang om de gebruiker te bereiken, tegen die tijd zou het misschien de opgegeven tijd hebben overschreden om de gebruiker te bereiken. Dit wordt meestal een verhoogd aantal hops genoemd
- Het e-maildomein van de gebruiker is lange tijd niet beschikbaar
- Het gebruikersaccount voor de applicatie is niet geactiveerd om e-mails te ontvangen
Lokalisatiebereik voor het testen van e-mails
Als de applicatie meerdere talen ondersteunt, moet de ondersteuning ook gelden voor e-mails.
Alle verzonden e-mails moeten in de taal van het gebruikersprofiel zijn. Als een gebruiker Engels als profieltaal heeft ingesteld, moeten alle e-mails die naar hem / haar worden verzonden in het Engels zijn. Als de profieltaal van de gebruiker Frans is, moeten alle naar hem / haar verzonden e-mails in het Frans zijn. De taal van het gebruikersprofiel kan eenmalige instellingen zijn of kan naar behoefte worden gewijzigd, afhankelijk van de instellingen van de applicatie.
E-mail moet worden verzonden in de taal die de gebruiker heeft op het moment dat deze wordt geactiveerd.
Gemeenschappelijke validatiepunten voor het testen van de lokalisatie van de e-mails zijn als volgt:
- Onderwerpregel
- Hoofdgedeelte van de e-mail
- Inhoud - tekst van het lichaam
- Linknaam / knopnaam
- Informatie over copyright
- Klantenservice details
Standaard / aanpassing van e-mails
E-mails kunnen aan de achterkant worden aangepast.
Bijvoorbeeld , ondersteunen weinig applicaties de gebruiker om e-mails aan te passen wanneer ze worden verzonden. De gebruiker kan hier de onderwerpregel en / of hoofdtekst van de e-mail wijzigen in zijn handige of voor het doel gemakkelijk te herkennen. In dit geval moet het testteam grondig worden getest, omdat de kans op binnendringing groot is.
Er moet worden getest op injecties - stuur HTML-code, Java-code, SQL, enz. Al deze zouden moeten mislukken om het beveiligingsniveau te verhogen. Als de applicatie het aanpassen van e-mails niet ondersteunt, volgen alle verzonden e-mails het standaardonderwerp / -tekst zoals ingesteld door een applicatie.
Gevolgtrekking
Het testen van e-mails is een belangrijke activiteit omdat de meeste componenten van de applicatie met deze functionaliteit zijn geïntegreerd.
Het zou de steun en moeite van het hele team moeten zijn om de e-mailfunctionaliteit van de applicatie volledig te testen. Dit moet goed worden gepland lang voordat het eigenlijke testen begint en moet hand in hand gaan tijdens het testen van elk onderdeel / bijbehorend onderdeel.
Bij e-mailtesten moeten voor elk e-mailtype afzonderlijke testcases worden geschreven die alle te testen aspecten omvatten. Dit moet worden uitgevoerd bij alle soorten tests. Regressietests, ad-hoctests, lokalisatietests, GAT-tests en productietests.
Alles wat in realtime fout gaat in e-mail, zal een slechte indruk achterlaten op de applicatie en klanten, en uiteindelijk wordt het doorgestuurd naar testers van die applicatie. E-mailvalidaties zijn dus een zeer cruciale en veelgevraagde activiteit bij het testen van software.
Over de auteur: Dit bericht is geschreven door STH-auteur Nandini K. Ze heeft meer dan 7 jaar ervaring in het testen van software, voornamelijk in het testen van webapplicaties.
help desk vragen om gebruikers te stellen
Laat het ons weten als u vragen / suggesties heeft.
Aanbevolen literatuur
- 10 BESTE e-mailtesttools voor uw volgende succesvolle e-mailcampagne
- Beste softwaretesttools 2021 [QA Test Automation Tools]
- Verschil tussen Desktop, Client Server Testing en Web Testing
- Handleiding voor het testen van webapplicaties
- Top 10 van e-mailverificatie- en validatiediensten in 2021
- Applicatie testen - In de basis van softwaretesten!
- Installeer uw applicatie op het apparaat en begin met testen vanuit Eclipse
- Primer eBook downloaden testen