email validation testing
Dagens opplæring handler om å teste e-postfunksjonaliteten til ethvert program.
I de fleste nett- og mobilapplikasjoner betraktes validering av e-postfunksjonen som en av de viktigste testingsdelene, for å sikre kvaliteten i e-postkomponenten i tillegg til andre komponenter i systemet.
E-post utløst under forskjellige scenarier anses å være validert ved å se etter alle komponentene som inkluderer en mal med e-post, lenker / knapper i feltene E-post, Fra, Til, Kopi, Bcc, Vedlegg, Innhold i henhold til e-postvarsling, etc.
Hva du vil lære:
- Hvorfor trenger vi e-posttesting?
Hvorfor trenger vi e-posttesting?
Hver komponent i systemet (web- / mobilapplikasjoner) kan ha forskjellige formål å sende e-post. Integrasjon mellom komponenten / komponentene og e-post spiller en viktig rolle i å nå sluttbrukeren med riktige varsler. Enhver uaktsomhet når vi validerer denne funksjonen, vil føre til misforståelser, dårlig navn hos kundene, hacking osv.
For eksempel , forestill deg en situasjon der en bruker har mottatt en e-post for å tilbakestille passordet. Hva om Tilbakestill passordlenke / -knappen eller URL-en som er gitt for å kopiere lim inn i en nettleser, ikke fungerer? Det eneste alternativet som er igjen her er å kontakte kundesupport, som kan bli en kjedelig ting eller forestille seg en situasjon der brukeren stadig mottar en e-post daglig angående forfallsdato for betaling av regning fra 10-15 dager tidligere eller mottar en påminnelse etter forfallsdatoen er bestått. - Irriterende er det ikke ??
Det er mange scenarier der e-post har blitt en integrert del av livet vårt, ettersom de er ment å holde brukeren oppdatert med presis informasjon.
Vanlige sanntidsscenarier og valideringspunkter for e-post
Valideringspunkter i testing av e-post varierer fra type til type, og igjen fra applikasjon til applikasjon. Vanligvis bør alle e-postmeldinger valideres for malen (som inkluderer applikasjonslogo, applikasjonsnavn, adressering av brukeren, bunntekstinnhold - copyright, kundesupportinformasjon), dato og tidsstempel for forskjellige tidssoner.
Her vil vi diskutere noen vanlige typer e-post som nesten alle er klar over (alle valideringspunktene gitt nedenfor er den grunnleggende kontrollen som testeren må utføre mens han tester e-post fra applikasjonen).
# 1) Aktiverings-e-post
Når en bruker registrerer seg for en applikasjon for første gang, må han / hun aktivere kontoen ved å klikke på aktiveringskoblingen sendt i e-post. Dette bekrefter også at brukerens oppgitte e-postadresse er gyldig og tilgjengelig.
Valideringspunktene er som følger:
- Aktiveringskobling eller knapp - Ved å klikke på den skal:
- Ta brukeren til respektive applikasjonsside med brukerkonto pålogget
- Brukerens e-postkonto skal bekreftes automatisk hvis applikasjonssiden nås via e-post
- Varighet - Kontroller hvor lenge lenken må klikkes og verifiseres.
- Bekreft innen angitt varighet
- Prøv å verifisere etter at varigheten har gått - Kontoen skal ikke aktiveres, og e-posten skal forbli ubekreftet
# 2) Glemt passord-e-post
Når en bruker glemmer passordet for å logge på applikasjonen, kan glemt passordflyt utføres for å motta en e-post med lenke for å tilbakestille passordet (funksjonen varierer fra applikasjon til applikasjon. Dette er den generelle).
Valideringspunktene er som følger:
- Tilbakestill passordkobling:
- Ved å klikke på den, bør brukeren gå til respektive applikasjonsside for å tilbakestille passordet
- Noen applikasjoner vil be brukeren om å svare på sikkerhetsspørsmålet før de viser siden for tilbakestillingspassord, og noen vil ha sikkerhetsspørsmål integrert med selve tilbakestillingssiden, og noen vil ikke ha denne funksjonen i det hele tatt
- Hvis brukeren tilbakestiller passordet vellykket, skal lenken i Glemt passord-e-post som er mottatt bli deaktivert og ikke-funksjonell
- Hvis brukeren avbryter tilbakestillingen av passordet, bør lenken i Glemt passord-e-post som er mottatt forbli aktivert
- Varighet - Kontroller hvor lenge lenken må klikkes for å tilbakestille passordet
- Klikk på lenken og tilbakestill passordet innen angitt varighet
- Prøv å klikke på lenken etter at varigheten har gått - Koblingen skal deaktiveres og utløpes
beste gratis fjerning av virus og skadelig programvare
# 3) Varsler om forfallsdato
Dette er for å minne brukeren om handlingen å ta i løpet av et bestemt antall dager. Dette er vanligvis regningsbetalingen, og tar grep på ventende varer (eksempel: godta eller avvise invitasjonen til et arrangement i et bestemt antall dager, sende skjemaer osv.).
Valideringspunktene er som følger:
- Antall forfallsdager / forfallsdato
- Hvis e-post varsler om et antall forfallsdager, bør antallet være enten null eller mer, null dager ment å være den gjeldende forfallsdatoen. Det skal ikke være i negative tall. Hvis e-post varsler om en forfallsdato (kalenderdato), bør datoen være den nåværende eller fremtiden.
- Type handling
- Sjekk hva slags handling som kreves. Det bør veldig tydelig angi hva slags handling brukeren må ta. Det være seg regningsbetalingen, innsendinger, tilbakemeldinger, etc.
# 4) Forfalte varsler
Dette for å informere brukeren om forfallsdato som har gått. Dette er vanligvis for å informere brukeren om at han / hun ikke har gjort noe med varene innen forfallsdato.
- Antall forfalte dager
- Sjekk at antall forfalte dager skal være enten en eller flere. Det skal aldri være null eller negative tall
- Frekvens
- Få applikasjoner vil kunne tilpasse forfalte e-poster som skal sendes daglig / ukentlig / månedlig, når forfallsdato er gått, til brukeren fullfører handlingen. Få søknader vil ha standardvarslingen som skal sendes bare en gang etter forfallsdatoen.
# 5) Abonnementer
Dette varierer i henhold til brukerens krav. Brukeren kan velge ett av følgende daglige, ukentlige, to-månedlige eller månedlige abonnementer. Dette vil vanligvis være for nyhetsbrev, oppdateringer, tilbud osv.
- Frekvens
- E-post skal sendes i henhold til brukervalg for et abonnement. Hvis det er daglig, skal e-post med abonnement sendes en gang om dagen. Hvis ukentlig, så en gang i uken. Og fortsetter ...
- Lenker
- Alle lenker i e-postmeldingen skal navigere til applikasjonens respektive side. Hvis e-postmeldingen er for oppdateringer, bør lenken omdirigere til siden der oppdateringene er ment å vises. Hvis e-posten er for tilbud, bør lenken omdirigere til Tilbud-siden i applikasjonen. Det avhenger av hvilken type abonnement brukeren har valgt.
# 6) Skjemaer
E-post her har til hensikt at brukeren skal gi tilbakemelding gjennom skjemaer / lenke til skjemaer. Valideringspunktene er som følger:
- Lenker
- Kobling i e-postmeldingen skal omdirigere brukeren til skjemainnleveringssiden for søknaden i henhold til typen skjema som brukeren må sende inn
- Når du har sendt den inn, skal du klikke på lenken på nytt for å varsle brukeren om at skjemaet allerede er sendt. Det skal ikke tillate brukeren å sende inn skjemaet på nytt
hvordan man sorterer et int-array i java
# 7) Bekreftelses-e-post
E-postmeldinger her er for å varsle brukeren om bekreftelsen av handlingen. Dette er vanligvis reservasjonsbekreftelser, ordrebekreftelser, spørrebekreftelser osv.
Valideringspunktene er som følger:
- Bekreftelsesdetaljer:
- Bestillingsnummer / bestillingsnummer skal være riktig og matche nummeret som vises i applikasjonsgrensesnittet. Ettersom det er identifikatoren for å spore ordrene / bestillingene, bør den være unik (skal valideres i backend - DB) i hele applikasjonen. Ingen bestillinger / bestillinger skal ha samme identifikator.
- Sammen med nummeret, bør det også valideres for type ordre, brukerinformasjon, faktureringsadresse, leveringsadresse og pris. All informasjonen skal være nøyaktig lik den brukeren har gitt i applikasjonsgrensesnittet.
- Lenker:
- En lenke i e-postmeldingen skal føre en bruker til bestillingsinformasjonssiden i applikasjonsgrensesnittet. Det bør være nøyaktig samsvar mellom informasjon i e-post og applikasjonsgrensesnitt
# 8) Chatutskrift
Her mottar en bruker hele chatutskriften som e-post. Dette er vanligvis når Live Chat med kundesupport er avsluttet.
Valideringspunktene er som nedenfor
- Detaljer
- Se etter navnet på personen som ga online støtte. Kontroller at hele chatten er til stede i e-posten med avsenderens detaljer for hver chatoppføring (Personnavn, dato og klokkeslett chatmeldingen ble sendt, etc.)
# 9) E-post med vedlegg
Brukeren mottar e-post med vedlegg. Vedlegg kan være passordbeskyttet / ubeskyttet. Dette er vanligvis uttalelser fra økonomiske domener, sluttbrukerlisensavtale for referanse, vilkår og betingelser for referanse, etc., dette varierer igjen fra applikasjon til applikasjon.
Valideringspunktene er som følger:
- Type vedlegg
- Gyldige filtyper skal sendes som vedlegg. Alle vedleggene som åpnes, skal skannes på virus før de lastes ned / åpnes. Dette kan igjen tilpasses på applikasjonsnivå i backend, som virusskanning som bare skal utføres når du laster ned, bare når du åpner, både for nedlasting og åpning.
- Passordbeskyttede vedlegg bør lastes ned uten å be om passordet. Men mens du åpner den enten fra e-posten selv eller åpner den nedlastede kopien, bør du alltid be om passordet. Feil passordoppføringer her vil være ubestemt, da den lokale kopien ikke kan spores online for å låse vedlegget
Typer e-post
E-posttypen kan være enten HTML (fargerik og attraktiv for brukerne, som interesserer brukeren for å lese e-postene fullstendig) eller vanlig tekst (bare en tekst).
HTML er mest foretrukket og er vanligvis satt som standard i nesten alle applikasjoner i backend. Hvis det er nødvendig, kan applikasjoner velge å sende e-post med vanlig tekst til brukerne. Dette krever igjen endringer i backend.
E-post utløserpoeng:
E-post kan sendes enten umiddelbart eller som sammendrag / batch. Umiddelbar e-post utløses av brukerens handling. Dette vil vanligvis være aktiverings-e-postmeldinger, tilbakestillingspassord-e-post, chat-transkripsjoner, bekreftelses-e-post osv., Dvs. at sammendrag / batch-e-post utløses basert på innstillingene i programmets backend.
E-postutløserpunkter vil bli definert til å utløse på det bestemte tidspunktet ( for eksempel 3rddag i hver uke kl. 12.00). Dette vil vanligvis være uttalelser fra økonomiske domener (kontoutskrifter), forfallsdato for regninger, forfalte varsler, abonnement, etc.,
Bouncebacks:
Det er et veldig vanlig scenario at e-postmeldinger spretter når de sendes til ugyldig e-postadresse. Vanligvis er e-postadressen som er deaktivert / ikke lenger er i bruk, og som ikke eksisterer i det hele tatt - kandidatene som spretter tilbake.
hva er den beste databaseprogramvaren
Serveren prøver vanligvis et spesifisert antall ganger å sende e-post til den tiltenkte adressen. Når den ikke når den tiltenkte e-postadressen, spretter den tilbake og gjør en oppføring på serveren for feil. Det vil være en annen server for å opprettholde denne typen aktiviteter, og kalles vanligvis bounce back-servere. Det kan være flere grunner til at en e-post mislykkes ved å nå brukeren.
Nedenfor er noen andre punkter for feil:
- E-postserveren er nede i lang tid
- Algoritmen for å finne en kort rute for å nå brukeren fungerer ikke som den skal, og det tar veldig lang tid å nå brukeren, på det tidspunktet ville det kanskje ha krysset den angitte tidsperioden for å nå brukeren. Dette kalles vanligvis økt antall humle
- Brukerens e-postdomene er nede i lang tid
- Brukerkonto for applikasjonen er ikke aktivert for å motta e-post
Lokaliseringsomfang for e-posttesting
Når applikasjonen støtter flere språk, bør støtten også omfatte e-post.
Alle sendte e-poster skal være på brukerprofilspråket. Hvis en bruker har angitt engelsk som profilspråk, skal alle e-postene som sendes til ham / henne være på engelsk. Hvis brukerens profilspråk er fransk, bør alle e-postene som sendes til ham / henne være på fransk. Brukerprofilspråk kan være engangsinnstillinger eller kan endres etter behov, noe som avhenger av programmets innstillinger.
E-post skal sendes på språket brukeren har på det tidspunktet den utløses.
Vanlige valideringspunkter for lokaliseringstesting av e-postene er som nedenfor:
- Emnefeltet
- E-postens kropp
- Innhold - tekst i kroppen
- Linknavn / knappnavn
- Informasjon om copyright
- Detaljer om kundesupport
Standard / Tilpasning av e-post
E-post kan tilpasses i backend.
For eksempel , få applikasjoner støtter brukeren til å tilpasse e-post når de blir sendt. Brukeren kan her endre emnelinjen og / eller brødteksten i e-posten slik at den er praktisk eller for det formål å gjenkjenne den lett. I dette tilfellet må testteamet gjøre grundige tester da sjansene for inntrenging er høye.
Testing må utføres for injeksjoner - send HTML-kode, Java-kode, SQL osv. Alt dette skulle mislykkes for å øke sikkerhetsnivået. Hvis applikasjonen ikke støtter tilpasning av e-post, vil alle e-postene som sendes følge standardtema / -tekst som angitt av en applikasjon.
Konklusjon
Testing av e-post er en viktig aktivitet da de fleste komponentene i applikasjonen er integrert med denne funksjonaliteten.
Det skal være hele teamets støtte og innsats å teste e-postfunksjonaliteten til applikasjonen fullstendig. Dette bør være godt planlagt mye før den faktiske testen starter, og skal gå hånd i hånd mens du tester hver komponent / tilhørende komponent.
E-posttesting bør ha separate testtilfeller skrevet for hver e-posttype som dekker alle aspektene som skal testes. Dette bør utføres i alle typer testing Regresjonstesting, Adhoc-testing, Lokaliseringstesting, UAT-testing og Produksjonstesting.
Alt som går galt i e-post i sanntid, vil gi et dårlig inntrykk på applikasjonen, kundene, og til slutt videreføres det til testere av den applikasjonen. Så e-postvalidering er veldig viktig og mye nødvendig aktivitet i programvaretesting.
Om forfatteren: Dette innlegget er skrevet av STH-forfatteren Nandini K. Hun har 7+ års erfaring med programvaretesting hovedsakelig innen nettapplikasjonstesting.
Gi oss beskjed hvis du har spørsmål / forslag.
Anbefalt lesing
- 10 BESTE testverktøy for e-post for din neste vellykkede e-postkampanje
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Forskjellen mellom Desktop, Client Server Testing og Web Testing
- Veiledning for testing av webapplikasjoner
- Topp 10 e-postbekreftelse og valideringstjenester i 2021
- Applikasjonstesting - inn i det grunnleggende om programvaretesting!
- Installere applikasjonen din på enheten og start testing fra Eclipse
- Testing Primer eBook Download