Bør QA-er bry seg om e-posttesting?

Ja, QA-er bør bry seg om testing av e-post. Denne artikkelen forklarer hvorfor, hvilke elementer som bør testes, og hvordan du kan gjøre e-posttesting enklere.

Først og fremst må du forstå hva slags e-posttesting vi snakker om.

Generelt viser e-posttesting til noen metoder for å kontrollere e-poster før de sendes. For e-postmarkedsførere handler det mer om innholdsanalyse og A/B-testing av kampanjer. For utviklere og QA-er som arbeider med apper som sender transaksjonelle e-poster, viser e-posttesting til en større prosess med handlinger – fra analyse av HTML til å sikre at e-poster blir levert. 

Jeg skal dekke:

• Viktigheten av e-posttesting
• 4 utfordringer ved QA-testing av e-post + løsninger 
• De viktigste e-postelementene du bør teste

La oss først se på viktigheten av e-posttesting for QA-er.

Du kan ikke la testingen skli ut: Her er hvorfor

Statistisk sett sendes og mottas over 300 milliarder e-poster hver dag. Det er vanskelig å forestille seg hvor mange e-poster med feil som sendes av selskaper daglig. Det er imidlertid ubestridelig at slike meldinger påvirker merkevarens omdømme og gir en dårlig brukeropplevelse.

Derfor er feilsøking av e-poster utviklings- og QA-teamets ansvar, slik at markedsføringsteamet kan lansere en velfungerende kampanje.

Hvis man hopper over dette stadiet, får det tre store negative konsekvenser:

Gjengivelsesfeil = dårlig brukeropplevelse 

Det er dessverre ikke alle e-postklienter som støtter HTML og CSS i samme grad. Outlook og Gmail-appen for kontoer som ikke er fra Google, viser for eksempel ikke bakgrunnsbilder. 

E-postklienter har ofte også spesifikke retningslinjer for utforming av e-poster – Yahoo Mail håndhever marger, mens Gmail klipper e-poster som er lengre enn 102 kB. 

Ettersom designere ikke nødvendigvis tar hensyn til gjengivelsesstandarder på tvers av et bredt utvalg e-postklienter, er det testerens jobb å oppfylle alle kravene. 

Derfor bør du fokusere på å teste kampanjer før du deler dem med brukerne. Ellers kan en person se e-posten din avkortet, med et forskjøvet oppsett, innhold som ikke reagerer, eller innhold som ikke støttes. Resultatet er garantert en dårlig brukeropplevelse, og det er større sjanse for at kundene ikke kommer tilbake. Hvis man tenker på at hele kampanjen inneholder ødelagte e-poster, er det frustrerende.

Leveringsevnen har en kostnad

Det er avgjørende å sikre en pålitelig forbindelse mellom e-poster i appen og sluttbrukerne for å støtte store brukerbaser. Siden mange team bruker e-postvarsler til å dele passord og informere fellesskapet om produktoppdateringer, er det frustrerende å ikke nå abonnentene. 

Innen e-postmarkedsføring er e-postleveringsevne en avgjørende faktor som bestemmer om en bruker får tilgang til den viktige meldingen din. Det er mange kriterier som avgjør en kampanjes leveringsevne: antall e-poster som rapporteres som søppelpost, brukernes interaksjoner med e-poster, avvisningsrater og annet. 

Det er krevende å bygge opp en stabil leveringsevne, og dette er vanligvis et ingeniørteams ansvar. En QA må være oppmerksom på når og hvor mange transaksjonelle e-poster et nettsted eller en app sender. På den annen side er det overraskende enkelt å kaste all innsatsen bort – noen få ødelagte lenker eller en mislykket søppelpostkontroll er nok til å spolere flere måneders arbeid. 

Testing av leveringsevne er en måte å forhindre slike frustrerende tilbakeslag på, ettersom det gjør det mulig for et QA-team å: 

• unngå søppelpostfeller (falske e-postadresser som legges ut av internettleverandører over hele nettet, og som ofte fanges opp av roboter og inkluderes i abonnentbasen) 
• finne ut hvilke elementer i e-postinfrastrukturen som er feilkonfigurert (IP, DNS-poster, poster for e-postautentisering osv.)
• sikre at innholdet ikke inneholder utløsere for søppelpost

Hvis en QA eller utvikler ignorerer søppelpostkontroller og testing av leveringsevne, når ikke kampanjer eller viktige e-poster frem til sluttbrukeren. Hvordan kan en bruker tilbakestille et passord eller få en registreringslenke hvis en uprøvd e-post forsvinner et sted i nettverket? På grunn av e-poster som ikke blir levert, kan et selskap miste kunder og oppleve andre forretningsmessige problemer.

Omdømmet påvirkes

Svært personaliserte e-poster er nå en sterk trend. Når man sender meldinger fulle av dynamiske tagger, kommer imidlertid ting ofte ut av kontroll. 

Det er ikke noe nytt at mottakere får brev med feil navn eller emnelinjer som «Hei, [username]». For merkevarer kan små forglemmelser ødelegge konverteringene for hele kampanjen og svekke merkevarens medieforbindelser. Årsaken er enkel: Du får ikke en ny sjanse til å gjøre et godt førsteinntrykk. Hvis du gjør en feil én gang, vil abonnentene sannsynligvis merke brevet som søppelpost eller legge igjen negativ tilbakemelding. Og merkevaren vil bli forbundet med avsendere av ødelagte e-poster, bare fordi noen hoppet over HTML/CSS-testing.

Relatert lesning: DE POSITIVE RESULTATENE AV NEGATIV TESTING

4 utfordringer ved QA-testing av e-post (+ måter å håndtere dem på)

Vi har skissert tre store negative konsekvenser av å sende e-poster med feil. Nå er det på tide å forstå utfordringene til de testerne som kjemper tappert med feilsøking av e-post. 

Vi kan ikke og vil ikke dømme. I årevis har det vært mange mangler i arbeidsflyter for e-posttesting som gjorde prosessen for manuell, langsom og ineffektiv.

Det finnes gjennomførbare løsninger som eliminerer utfordringene ved testing. La oss se på hvordan du kan håndtere de mest irriterende ulempene. 

1. Test-e-poster sendes til ekte brukere

Dette irriterende problemet skyldes at QA-team bruker produksjonsdomener til å gjennomføre testøkter. Dermed er det lett å krysse grensen og ved et uhell sende en testmelding til en liste med abonnenter. 

I tillegg fører bruk av produksjonsserveren til testing til at sendevolumene for et domene blåses opp og domenets autoritet svekkes. 

Det er enkelt å sørge for at du ikke sender e-post til ekte brukere ved en feil, så lenge du bruker et separat miljø til testing. Det finnes to måter å teste e-poster på en trygg måte:

• Testing i et utviklingsmiljø ved hjelp av API-integrasjon
• Bruk av verktøy som etterligner arbeidet til ekte SMTP-servere, med mulighet til å kontrollere vanlige SMTP-porter og andre infrastrukturelementer. 

2. Lav leveringsgrad (eller at e-poster havner i søppelpostmapper)

Hvis forhåndsvisnings-e-postene dine havner i «søppelpost», er det ikke nødvendigvis et faresignal. Før du varsler markedsføringsteamet og dobbeltsjekker infrastrukturen, bør du utelukke følgende muligheter:

• Forhåndsvisnings-e-posten inneholder fortsatt fylltekst. Når du sender test-e-poster, må du sørge for at meldingsteksten er nøyaktig den samme som brukeren vil se. Elementer som «Lorem Ipsum dolor» utløser søppelpostfiltre og reduserer leveringsgraden for en test-e-post. 
• Du åpner ikke dine egne test-e-poster. Hvis du bruker din egen adresse til å teste e-poster, vil internettleverandører, med mindre du samhandler med dem, merke brevene som irrelevante og begynne å sende dem til søppelpost. 
• Avsender- og mottakeradressen er den samme. For å levere e-poster må e-postklienter kreve at avsenderens og mottakerens adresser ikke er den samme postkassen. Når du deler en testmelding med deg selv, bør du derfor velge en annen e-postadresse enn den du bruker til å sende testen. 
• Ingen lenke for «Avslutt abonnement». Utsendelser som ikke har en bunntekst med «Avslutt abonnement», har 99,9 % sjanse for å bli avvist eller merket som søppelpost. 

3. Dårlig gjengivelse og responsivitet på tvers av enheter

En annen hindring QA-team møter, er å oppdage at meldinger vises forskjellig i ulike e-postklienter eller på ulike enhetstyper. Hvis dette gjelder testutsendelsen din, er dette noen klientspesifikke hensyn til gjengivelse som du bør kontrollere i e-postteksten:

Gmail:

• Bilder støttes som standard. 
• E-poster som er større enn 102 kB, beskjæres automatisk. 
• <style>-taggen plasseres i toppteksten til e-posten. 
• Automatisk skalering av e-poster på iPhone (bilder vil se ut til å være forskjøvet, så det er bedre å sette «padding:0» i <body>. 
• Minste tekststørrelse er 10,5 pt for brødtekst og 16,5 pt for overskrifter, slik at teksten er lett å lese på smarttelefoner. 

Outlook:

• Ingen støtte for bakgrunnsbilder. 
• Ingen støtte for interaktive elementer som skjemaer eller avmerkingsbokser. 
• Ingen støtte for HTML5-videoer eller GIF-er. 
• Begrenset støtte for innvendig marg. 

4. Lav testeffektivitet

På 2000-tallet var testing av e-post manuell, statisk og tidkrevende. Testteamene måtte generere e-poster fra bunnen av og sende dem til testadresser. Den gode nyheten er at de fleste av disse trinnene enkelt kan automatiseres i dag. 

Her er noen verktøy som hjelper QA-team med å bruke mindre tid på testing av enkeltelementer i e-poster:

• Forhåndsvisning av e-post: Litmus
• E-postservere: GMass
• E-post-API: Mailosaur
• Søppelpostsjekk: SpamAssassin
• Leveringsevne for e-post: Mail-Tester
• HTML-sjekk: HTML Email Check
• System for nettleserautomatisering: Selenium

Hvis du trenger en fullstack-testløsning som lar deg teste alle de tekniske aspektene ved e-post, inkludert SMTP, API og HTML/CSS, bør du velge samarbeidsvennlige verktøy som Mailtrap. 

E-posttesting er bare én del av kvalitetssikringen. For en helhetlig tilnærming til QA kan du utforske vår guide til de beste verktøyene for programvaretesting.

De viktigste e-postelementene du bør teste

Nå som du vet hvorfor det ikke finnes noen vei utenom e-posttesting, og forstår hvordan du skal håndtere de viktigste utfordringene QA-team møter når de gjennomfører testøkter, er det på tide å lage en trinnvis teststrategi som sikrer høy leveringsevne og feilfri gjengivelse av e-postene dine. 

Her er de viktigste typene e-posttester et QA-team bør gjennomføre.

1. SMTP-overvåking

SMTP-feil er en vanlig årsak til problemer med levering av e-post eller fullstendige feil i e-postinfrastrukturen. Her er problemene QA-teamene må være oppmerksomme på:

• Brannmuren blokkerer kommunikasjonen.
• Serverresponsen tar for lang tid. 
• SMTP-serveren kobler til feil vertsnavn. 
• SMTP støtter ikke de angitte kommandoene. 

For å effektivisere SMTP-vurderingen bruker QA-team dedikerte verktøy: Web Biz eller Wormly.

2. Testing av e-post-API

API-testing gjør det mulig for utviklere å teste e-poster uten å gå ut av IDE-en. Ved å bruke API-er kan du:

• Automatisere prosessen mest mulig.
• Hente e-poster i kode. 
• Hente ut og verifisere innholdet i en test-e-post. 
• Bruke mønstergjenkjenning. 
• Sende test-e-poster med vedlegg. 

Ulike programmeringsspråk kjører ulike skript for API-testing av e-post. For å effektivisere prosessen kan du vurdere å implementere verktøy som Mandrill eller MailSlurp. 

3. Lokal utsending av test-e-post 

En annen måte å teste e-poster på er å konfigurere en lokal server. På denne måten avlaster QA-teamene produksjonsmiljøet for utsendingsbelastningen og skiller testingen fra en reell kampanje. 

E-posttesting på en lokal server er en nyttig måte å sikre at du ikke ved en feil sender en testgruppe til abonnentene. Verktøy du bør vurdere, er Mailhog eller Mailcatcher. 

4. Testing av e-postlevering og søppelpost

Som nevnt hjelper testing av e-postlevering og søppelpost med å kontrollere omdømmet til domenet og IP-en din, samt avdekke om en avsenderadresse er svartelistet av internettleverandører. 

 Mail-Tester eller GlockApps kan være nyttige.

Konklusjon

I QA-miljøet kommer e-posttesting ofte i andre rekke etter funksjons- og ytelsestesting. Sannheten er at QA-team ikke bør undervurdere feilsøking av e-post og testing av infrastruktur. Prøv fremgangsmåtene som er nevnt i denne artikkelen. Fortell oss hvilke verktøy for e-posttesting du foretrekker, i kommentarfeltet. 

For mer om dette og andre råd fra QA-eksperter, må du ikke glemme å abonnere på nyhetsbrevet til QA Lead for å holde deg oppdatert på det beste innen kvalitetsutvikling.

Relatert verktøyliste: DE 10 BESTE VERKTØYENE FOR E-POSTTESTING FOR OPTIMAL LEVERING

Ikke slutt å lære nå! Sjekk ut denne podkasten: AUTOMATISERT TESTING MED TESTRIGOR-SJEF ARTEM GOLUBEV OG PAUL GROSSMAN