Bør QA’ere bekymre sig om e-mailtest?

Ja, QA'er bør interessere sig for e-mailtest. Denne artikel forklarer hvorfor, hvilke elementer der skal testes, og hvordan e-mailtest kan gøres ubesværet.

Først og fremmest skal du forstå, hvilken type e-mailtest vi taler om.

Generelt henviser e-mailtest til nogle få metoder til at kontrollere e-mails, før de sendes. For e-mailmarkedsførere handler det mere om indholdsanalyse og A/B-test af kampagner. For udviklere og QA'er, der arbejder med apps, som sender transaktionsmails, henviser e-mailtest til en større række handlinger – fra analyse af HTML til sikring af e-maillevering. 

Jeg gennemgår:

• Vigtigheden af e-mailtest
• 4 udfordringer ved QA-e-mailtest + løsninger 
• Vigtigste e-mailelementer, du bør teste

Først og fremmest er det vigtigt for QA'er at teste e-mails.

Du kan ikke tillade dig at forsømme testningen: Her er hvorfor

Statistisk set sendes/modtages der mere end 300 milliarder e-mails hver dag. Det er svært at forestille sig antallet af fejlbehæftede e-mails, som virksomheder sender dagligt. Det kan dog ikke benægtes, at sådanne meddelelser påvirker et brands omdømme og giver en dårlig brugeroplevelse.

På den måde er fejlfinding af e-mails udviklings-/QA-teamets ansvar for at sikre, at marketingteamet kan lancere en ordentlig kampagne.

Hvis man springer denne fase over, fører det til tre væsentlige negative konsekvenser:

Visningsfejl = dårlig brugeroplevelse 

Desværre understøtter ikke alle e-mailklienter HTML og CSS i samme grad. Outlook eller Gmail-appen for ikke-Google-konti viser f.eks. ikke baggrundsbilleder. 

På samme måde har e-mailklienter ofte specifikke retningslinjer for design af e-mails – Yahoo Mail håndhæver margener, mens Gmail klipper meddelelser, der er længere end 102 kB. 

Da designere ikke nødvendigvis tager hensyn til visningsstandarder på tværs af en lang række e-mailklienter, er det testerens opgave at opfylde alle kravene. 

Derfor bør du fokusere på at teste kampagner, før du deler dem med brugerne. Ellers kan en person se din meddelelse afkortet, med et forskudt layout, uden respons eller med indhold, der ikke understøttes. Som følge heraf er en dårlig brugeroplevelse garanteret, og der er større risiko for, at kunderne ikke vender tilbage. Hvis man tager i betragtning, at hele kampagnen indeholder ødelagte e-mails, er det frustrerende.

E-maillevering har konsekvenser

Det er afgørende at sikre en pålidelig forbindelse mellem e-mails i appen og slutbrugerne for at understøtte store brugerbaser. Da mange teams bruger e-mailnotifikationer til at dele adgangskoder og informere fællesskabet om produktopdateringer, er det frustrerende ikke at kunne nå abonnenterne. 

Inden for e-mailmarkedsføring er e-maillevering den faktor, der afgør, om en bruger kan få adgang til din vigtige meddelelse. Der er mange kriterier, som bestemmer en kampagnes leveringsrate: antallet af e-mails, der er blevet rapporteret som spam, brugernes interaktioner med meddelelser, afvisningsrater og meget mere. 

Det kræver hårdt arbejde at opbygge en problemfri e-maillevering, og det er normalt et udviklingsteams ansvar. En QA-medarbejder skal være opmærksom på, hvornår og hvor mange transaktionsmails et websted eller en app sender. Omvendt er det overraskende let at spilde hele indsatsen – nogle få ødelagte links eller en mislykket spamkontrol er nok til at ødelægge måneders arbejde. 

Test af e-maillevering er en måde at forhindre sådanne frustrerende tilbageslag på, da det giver et QA-team mulighed for: 

• undgå spamfælder (falske e-mailadresser, som internetudbydere placerer overalt på nettet, og som ofte opsnappes af bots og inkluderes i abonnentbasen) 
• finde ud af, hvilke elementer i e-mailinfrastrukturen der er konfigureret forkert (IP, DNS-poster, poster til e-mailgodkendelse osv.)
• sikre, at der ikke er spamudløsere i indholdet

Hvis en QA-medarbejder eller udvikler ignorerer spamkontroller og test af e-maillevering, når kampagner eller vigtige e-mails ikke frem til slutbrugeren. Hvordan kan en bruger nulstille en adgangskode eller få et registreringslink, hvis en utestet e-mail flyver et eller andet sted hen på et netværk? På grund af ikke-leverede e-mails kan en virksomhed miste kunder og opleve andre forretningsmæssige fiaskoer.

Omdømmet påvirkes

Meget personaliserede e-mails er i øjeblikket en stærk tendens. Men når man sender meddelelser fyldt med dynamiske mærker, løber tingene ofte af sporet. 

Det er ikke noget nyt for modtagere at få breve med forkerte navne eller emnelinjer som “Hej, [brugernavn]”. For varemærker ødelægger små forsømmelser konverteringerne i hele kampagnen og skader brandets relationer til medierne. Årsagen er enkel: Man får ikke en chance til for at gøre et godt førstehåndsindtryk. Hvis du laver en fejl én gang, vil abonnenter sandsynligvis markere brevet som spam eller give negativ feedback. Og brandet vil blive forbundet med afsendere af fejlbehæftede e-mails, blot fordi nogen sprang HTML/CSS-test over.

Relateret læsning: DE POSITIVE RESULTATER AF NEGATIV TESTING

4 smertepunkter ved QA-test af e-mails (+ måder at håndtere dem på)

Vi har beskrevet tre væsentlige skadelige effekter ved at sende fejlbehæftede e-mails. Nu er det tid til at forstå smertepunkterne for de testere, der kæmper sig tappert gennem fejlfinding af e-mails. 

Vi kan og vil ikke dømme. I årevis har der været mange mangler i arbejdsgangene for e-mailtest, som gjorde processen for manuel, langsom og ineffektiv.

Der findes gennemførlige løsninger, som eliminerer smertepunkterne ved testning. Lad os se på, hvordan man håndterer de mest irriterende ulemper. 

1. Test-e-mails sendes til rigtige brugere

Dette irriterende problem skyldes, at QA-teams bruger produktionsdomæner til at køre testsessioner. Som følge heraf er det let at overskride grænsen og ved et uheld sende en testbesked til en liste over abonnenter. 

Desuden øger brugen af produktionsserveren til at køre test afsendelsesvolumen for et domæne og skader domænets autoritet. 

Det er nemt at sikre, at du ikke ved en fejl sender e-mails til rigtige brugere, så længe du bruger et separat miljø til testning. Der er to måder at teste e-mails sikkert på:

• Testning i udviklingsmiljøet ved hjælp af API-integration
• Brug af værktøjer, der efterligner rigtige SMTP-serveres funktion med mulighed for at kontrollere almindelige SMTP-porte og andre infrastrukturelementer. 

2. Lav leveringsevne (eller ender i spammapper)

Hvis dine forhåndsvisnings-e-mails ender i ’Spam’, er det ikke nødvendigvis et advarselstegn. Før du alarmerer marketingteamet og dobbelttjekker infrastrukturen, skal du udelukke følgende muligheder:

• Din forhåndsvisnings-e-mail indeholder stadig pladsholdertekst. Når du sender test-e-mails, skal du sikre dig, at meddelelsens brødtekst er præcis den, som en bruger vil se. Elementer som “Lorem Ipsum dolor” udløser spamfiltre og forringer leveringsevnen for en test-e-mail. 
• Du åbner ikke dine egne test-e-mails. Hvis du bruger din egen adresse til at teste e-mails, vil internetudbydere, medmindre du interagerer med dem, markere brevene som irrelevante og begynde at sende dem til spam. 
• Afsender- og modtageradressen er den samme. For at levere e-mails korrekt kræver e-mailklienter, at afsenderens og modtagerens adresser ikke er den samme postkasse. Når du deler en testbesked med dig selv, skal du derfor vælge en anden e-mailadresse end den, du bruger til at sende testen. 
• Intet “Afmeld abonnement”-link. Udsendelser uden en “Afmeld abonnement”-sidefod har 99,9 % risiko for at blive afvist eller markeret som spam. 

3. Dårlig visning og responsivitet på tværs af enheder

En anden udfordring, som QA-teams støder på, er at opdage, at meddelelser vises forskelligt på tværs af e-mailklienter eller enhedstyper. Hvis det er tilfældet for din testudsendelse, er her nogle klientspecifikke overvejelser om visning, som du bør validere e-mailens brødtekst på tværs af:

Gmail:

• Billeder understøttes som standard. 
• E-mails, der er større end 102 kB, beskæres automatisk. 
• <style>-tagget placeres i e-mailens head-element. 
• Automatisk skalering af e-mails på iPhones (billeder vil se ud til at være forskudt fra midten, så det er bedre at angive “padding:0” i <body>. 
• Den minimale tekststørrelse er 10,5 pt for brødtekst og 16,5 pt for overskrifter for at sikre læsbarhed på smartphones. 

Outlook:

• Ingen understøttelse af baggrundsbilleder. 
• Ingen understøttelse af interaktive elementer som formularer eller afkrydsningsfelter. 
• Ingen understøttelse af HTML5-videoer eller GIF'er. 
• Begrænset understøttelse af indvendig margen. 

4. Lav testeffektivitet

Tilbage i 00'erne var e-mailtest manuel, statisk og besværlig. Testteams skulle oprette e-mails fra bunden og sende dem til testadresser. Den gode nyhed er, at de fleste af disse trin i dag nemt kan automatiseres. 

Her er nogle værktøjer, der hjælper QA-teams med at bruge mindre tid på at teste enkelte e-mailelementer:

• Forhåndsvisning af e-mails: Litmus
• E-mailservere: GMass
• E-mail-API: Mailosaur
• Spamkontrol: SpamAssassin
• Levering af e-mails: Mail-Tester
• HTML-kontrol: HTML Email Check
• System til browserautomatisering: Selenium

Hvis du har brug for en komplet testløsning, der giver dig mulighed for at teste alle tekniske aspekter af e-mail, herunder SMTP, API, HTML/CSS, bør du foretrække samarbejdsvenlige værktøjer som Mailtrap. 

E-mailtest er kun ét aspekt af kvalitetssikring. Hvis du vil have en helhedsorienteret tilgang til QA, kan du se vores guide til de bedste værktøjer til softwaretest.

Vigtige e-mailelementer, du bør teste

Nu hvor du ved, hvorfor man ikke kan undlade e-mailtest, og forstår, hvordan du håndterer de største udfordringer, QA-teams står over for under testforløb, er det tid til at udarbejde en trinvis teststrategi, der sikrer høj leveringsevne og fejlfri gengivelse af dine e-mails. 

Her er de vigtigste typer e-mailtest, som et QA-team bør gennemføre.

1. SMTP-overvågning

SMTP-fejl er en almindelig årsag til problemer med levering af e-mails eller fuldstændige fejl i e-mailinfrastrukturen. Her er de problemer, QA-medarbejdere skal være opmærksomme på:

• Firewallen blokerer kommunikationen.
• Serverens svar tager for lang tid. 
• SMTP-serveren opretter forbindelse til det forkerte værtsnavn. 
• SMTP understøtter ikke de angivne kommandoer. 

For at effektivisere SMTP-vurderingen bruger QA-teams dedikerede værktøjer: Web Biz eller Wormly.

2. Test af e-mail-API

API-test giver udviklere mulighed for at teste e-mails uden at forlade IDE'en. Ved at bruge API'er kan du:

• Automatisere processen mest muligt.
• Hente e-mails i kode. 
• Udtrække og verificere indholdet af en test-e-mail. 
• Anvende mønstergenkendelse. 
• Sende test-e-mails med vedhæftede filer. 

Forskellige programmeringssprog kører forskellige scripts til API-test af e-mails. For at effektivisere processen kan du overveje at implementere værktøjer som Mandrill eller MailSlurp. 

3. Lokal afsendelse af test-e-mails 

En anden måde at teste e-mails på er ved at konfigurere en lokal server. På den måde aflaster QA-teams produktionsmiljøet for afsendelsen og adskiller test fra en kampagne i den virkelige verden. 

E-mailtest på en lokal server er en nyttig måde at sikre, at du ikke ved en fejl sender en testgruppe til abonnenter. Værktøjer, du kan overveje, er Mailhog eller Mailcatcher. 

4. Test af e-maillevering og spam

Som nævnt hjælper test af e-maillevering og spam med at kontrollere omdømmet for dit domæne og din IP-adresse samt opdage, om en afsenderadresse er blevet sortlistet af internetudbydere. 

 Mail-Tester eller GlockApps kan være nyttige.

Konklusion

I QA-fællesskabet kommer e-mailtest ofte i anden række efter funktionstest og ydelsestest. Sandheden er, at QA-teams ikke bør undervurdere fejlfinding af e-mails og test af infrastrukturen. Prøv metoderne, der er nævnt i denne artikel. Fortæl os, hvilke værktøjer til e-mailtest du foretrækker, i kommentarfeltet. 

Hvis du vil vide mere om dette og få andre råd fra QA-eksperter, så glem ikke at abonnere på The QA Lead-nyhedsbrevet, så du kan følge med i det bedste inden for kvalitetsteknik.

Relateret liste over værktøjer: DE 10 BEDSTE VÆRKTØJER TIL TEST AF E-MAILS FOR OPTIMAL LEVERING

Stop ikke med at lære nu! Lyt til denne podcast: AUTOMATISERET TEST MED TESTRIGOR-CEO ARTEM GOLUBEV & PAUL GROSSMAN