Moeten QA’s zich zorgen maken over e-mailtesten?
Ja, QA's zouden zich moeten bekommeren om e-mailtesten. In dit artikel worden de redenen uitgelegd, evenals de elementen die je moet testen en hoe je e-mailtesten moeiteloos maakt.
Allereerst moet je begrijpen over welk soort e-mailtesten we het hebben.
Over het algemeen verwijst e-mailtesten naar enkele methoden om e-mails te controleren voordat ze worden verzonden. Voor e-mailmarketeers draait het vooral om contentanalyse en A/B-testen van campagnes. Voor ontwikkelaars en QA's die werken met apps die transactionele e-mails versturen, verwijst e-mailtesten naar een grotere cyclus van acties – van het analyseren van HTML tot het garanderen van e-mailbezorgbaarheid.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Ik bespreek:
- Belang van e-mailtesten
- 4 knelpunten bij QA-e-mailtesten + oplossingen
- Belangrijkste e-mailelementen die je moet testen
Om te beginnen: het belang van e-mailtesten voor QA's.
Je kunt testen niet laten versloffen: dit is waarom
Statistisch gezien worden er dagelijks 300+ miljard e-mails verzonden en ontvangen. Het is moeilijk voor te stellen hoeveel e-mails met fouten bedrijven dagelijks versturen. Het staat echter buiten kijf dat dergelijke berichten de reputatie van een merk aantasten en een slechte gebruikerservaring bieden.
Op deze manier is het debuggen van e-mails de verantwoordelijkheid van het dev-/QA-team, om ervoor te zorgen dat een marketingteam een goede campagne kan lanceren.
Het overslaan van deze fase leidt tot drie belangrijke negatieve gevolgen:
Renderfouten = slechte gebruikerservaring
Helaas ondersteunen niet alle e-mailclients HTML en CSS in dezelfde mate. Outlook of de Gmail-app voor niet-Google-accounts geeft bijvoorbeeld geen achtergrondafbeeldingen weer.
Op dezelfde manier hanteren e-mailclients vaak specifieke richtlijnen voor het ontwerpen van e-mails: Yahoo Mail dwingt marges af, terwijl Gmail berichten afkapt die langer zijn dan 102 kB.
Omdat ontwerpers niet per se rekening houden met weergavestandaarden voor een groot aantal e-mailclients, is het de taak van een tester om aan alle eisen te voldoen.
Daarom moet je je richten op het testen van campagnes voordat je ze met gebruikers deelt. Anders kan iemand je bericht afgekapt zien, met een verschoven lay-out, niet-reagerende of niet-ondersteunde inhoud. Als gevolg daarvan is een slechte UX gegarandeerd en is de kans groter dat klanten niet terugkomen. Als je bedenkt dat de hele campagne kapotte e-mails bevat, is dat frustrerend.
E-mailbezorgbaarheid heeft gevolgen
Het garanderen van een betrouwbare route tussen e-mails in een app en eindgebruikers is essentieel om grote gebruikersgroepen te ondersteunen. Omdat veel teams e-mailmeldingen gebruiken om wachtwoorden te delen en de community op de hoogte te brengen van productupdates, is het vervelend als abonnees niet kunnen worden bereikt.
Bij e-mailmarketing is e-mailbezorgbaarheid een factor X die bepaalt of een gebruiker toegang krijgt tot je belangrijke bericht. Er zijn veel criteria die het bezorgbaarheidspercentage van een campagne bepalen: het aantal e-mails dat als spam is gemeld, gebruikersinteracties met berichten, bouncepercentages en andere factoren.
Een soepele e-mailbezorgbaarheid opbouwen is hard werken en dit is meestal de verantwoordelijkheid van een engineeringteam. Een QA moet zich bewust zijn van wanneer en hoeveel transactionele e-mails een website of app verstuurt. Daarentegen is het verrassend eenvoudig om alle inspanningen teniet te doen – een paar kapotte links of een mislukte spamcontrole zijn genoeg om maanden werk te laten ontsporen.
Bezorgbaarheidstesten zijn een manier om zulke frustrerende tegenslagen te voorkomen, omdat ze een QA-team in staat stellen om:
- spamvallen te vermijden (nep-e-mailadressen die door internetproviders overal op het web zijn geplaatst, vaak door bots worden verzameld en aan het abonneebestand worden toegevoegd)
- te achterhalen welke elementen van de e-mailinfrastructuur verkeerd zijn geconfigureerd (IP-adres, DNS-records, e-mailauthenticatierecords enzovoort)
- ervoor te zorgen dat de inhoud geen spamtriggers bevat
Als een QA of ontwikkelaar spamcontroles en bezorgbaarheidstesten negeert, bereiken campagnes of belangrijke e-mails de eindgebruiker niet. Hoe kan een gebruiker een wachtwoord resetten of een registratielink ontvangen als een ongeteste e-mail ergens binnen een netwerk blijft rondzweven? Door niet-bezorgde e-mails kan een bedrijf klanten verliezen en andere zakelijke problemen ondervinden.
De reputatie wordt aangetast
Op dit moment zijn sterk gepersonaliseerde e-mails een duidelijke trend. Wanneer berichten echter vol dynamische labels worden verzonden, loopt het vaak uit de hand.
Het is geen nieuws voor ontvangers om e-mails te krijgen met verkeerde naamlabels of onderwerpregels zoals “Hallo, [username]”. Voor merken zorgen kleine onoplettendheden ervoor dat de conversies van de hele campagne instorten en dat de mediarelaties van merken verslechteren. De reden is eenvoudig: je krijgt geen tweede kans om een eerste indruk te maken. Als je één keer een fout maakt, zullen abonnees de e-mail waarschijnlijk als spam markeren of negatieve feedback achterlaten. En het merk zal worden geassocieerd met afzenders van defecte e-mails, alleen maar omdat iemand de HTML/CSS-testen heeft overgeslagen.
Gerelateerd artikel: DE POSITIEVE RESULTATEN VAN NEGATIEF TESTEN
4 pijnpunten van QA-e-mailtesten (+ manieren om ze te omzeilen)
We hebben drie belangrijke schadelijke effecten van het versturen van e-mails met fouten uiteengezet. Het is tijd om de pijnpunten te begrijpen van die testers die zich dapper door het debuggen van e-mails heen worstelen.
We kunnen en zullen niet oordelen. Jarenlang waren er veel tekortkomingen in workflows voor het testen van e-mails, waardoor het proces te handmatig, traag en inefficiënt was.
Er zijn haalbare oplossingen die pijnpunten bij het testen wegnemen. Laten we bekijken hoe je de meest vervelende ongemakken kunt aanpakken.
1. Test-e-mails gaan naar echte gebruikers
Dit vervelende probleem komt voort uit het feit dat QA-teams productiedomeinen gebruiken om testsessies uit te voeren. Daardoor is het gemakkelijk om de grens te overschrijden en per ongeluk een testbericht naar een lijst met abonnees te sturen.
Bovendien zorgt het gebruik van de productieserver om tests uit te voeren ervoor dat de verzendvolumes voor een domein worden opgeblazen en dat de domeinautoriteit wordt geschaad.
Je voorkomt eenvoudig dat je per ongeluk echte gebruikers e-mailt, zolang je een aparte omgeving voor testen gebruikt. Er zijn twee manieren om e-mails veilig te testen:
- Testen in een ontwikkelomgeving met API-integratie
- Tools gebruiken die de werking van echte SMTP-servers nabootsen, met de mogelijkheid om veelgebruikte SMTP-poorten en andere infrastructuurelementen te controleren.
2. Lage afleverbaarheid (of belanden in spamfolders)
Als je voorbeeldmails in ‘Spam’ terechtkomen, is dat niet per se een alarmsignaal. Voordat je het marketingteam waarschuwt en de infrastructuur opnieuw controleert, moet je de volgende mogelijkheden uitsluiten:
- Je voorbeeldmail bevat nog steeds opvultekst. Zorg er bij het versturen van test-e-mails voor dat de tekst van het bericht exact overeenkomt met wat een gebruiker zal zien. Elementen zoals “Lorem Ipsum dolor” activeren spamfilters en brengen de afleverbaarheid van een test-e-mail sterk omlaag.
- Je opent je eigen test-e-mails niet. Als je je eigen adres gebruikt om e-mails te testen, zullen internetproviders de berichten als irrelevant markeren en ze naar spam gaan sturen, tenzij je ermee interacteert.
- Het adres van de afzender en ontvanger is hetzelfde. Om e-mails succesvol af te leveren, vereisen e-mailclients dat de adressen van de afzender en ontvanger niet dezelfde mailbox zijn. Kies dus bij het delen van een testbericht met jezelf een ander e-mailadres dan het adres dat je gebruikt om de test te verzenden.
- Geen link voor “Afmelden”. Batches zonder een voettekst met “Afmelden” hebben 99.9% kans om te worden teruggestuurd of als spam te worden gemarkeerd.
3. Slechte weergave en responsiviteit op verschillende apparaten
Een ander obstakel waar QA-teams tegenaan lopen, is de ontdekking dat berichten er in verschillende e-mailclients of op verschillende apparaattypen anders uitzien. Als dit het geval is voor je testbatch, zijn hier enkele client-specifieke aandachtspunten voor de weergave waarmee je de inhoud van de e-mail moet controleren:
Gmail:
- Afbeeldingen worden standaard ondersteund.
- E-mails die groter zijn dan 102 kB worden automatisch ingekort.
- De tag <style> wordt in de kop van de e-mail geplaatst.
- Automatische schaling van e-mails op iPhones (afbeeldingen lijken niet gecentreerd, dus je kunt beter “padding:0” in <body> plaatsen).
- De minimale tekstgrootte is 10.5pt voor tekst en 16.5pt voor koppen om de leesbaarheid op smartphones te garanderen.
Outlook:
- Geen ondersteuning voor achtergrondafbeeldingen.
- Geen ondersteuning voor interactieve elementen zoals formulieren of selectievakjes.
- Geen ondersteuning voor HTML5-video's of GIF's.
- Beperkte ondersteuning voor opvulling.
4. Lage testefficiëntie
In de jaren 2000 waren e-mailtests handmatig, statisch en tijdrovend. Testteams moesten e-mails vanaf nul opstellen en deze naar testadressen sturen. Het goede nieuws is dat de meeste van deze stappen tegenwoordig eenvoudig kunnen worden geautomatiseerd.
Hier zijn enkele tools die QA-teams helpen minder tijd te besteden aan het testen van afzonderlijke e-mailelementen:
- E-mailvoorbeeld: Litmus
- E-mailservers: GMass
- E-mail-API: Mailosaur
- Spamcontrole: SpamAssassin
- E-mailafleverbaarheid: Mail-Tester
- HTML-controle: HTML Email Check
- Systeem voor browserautomatisering: Selenium
Als je een volledige testoplossing nodig hebt waarmee je alle technische aspecten van e-mail kunt testen, waaronder SMTP, API en HTML/CSS, geef dan de voorkeur aan tools die samenwerking ondersteunen, zoals Mailtrap.
E-mailtesten zijn slechts één aspect van kwaliteitsborging. Bekijk voor een holistische QA-aanpak onze gids met de beste tools voor softwaretesten.
Belangrijkste e-mailelementen die je moet testen
Nu je weet waarom je e-mailtesten niet kunt overslaan en begrijpt hoe je omgaat met de belangrijkste obstakels waarmee QA-teams tijdens testsessies te maken krijgen, is het tijd om een stapsgewijze teststrategie op te stellen die zorgt voor een hoge afleverbaarheid en een onberispelijke weergave van je e-mails.
Dit zijn de belangrijkste soorten e-mailtests die een QA-team moet uitvoeren.
1. SMTP-monitoring
SMTP-fouten zijn een veelvoorkomende oorzaak van problemen met e-mailafleverbaarheid of volledige uitval van de e-mailinfrastructuur. Dit zijn de problemen waarop QA-medewerkers moeten letten:
- De firewall blokkeert de communicatie.
- De serverreactie duurt te lang.
- De SMTP-server maakt verbinding met de verkeerde hostnaam.
- SMTP ondersteunt de opgegeven opdrachten niet.
Om de SMTP-beoordeling te stroomlijnen, gebruiken QA-teams speciale tools: Web Biz of Wormly.
2. Testen van de e-mail-API
Met API-tests kunnen ontwikkelaars e-mails testen zonder de IDE te verlaten. Met API's kun je:
- Het proces maximaal automatiseren.
- E-mails in code ophalen.
- De inhoud van een test-e-mail extraheren en verifiëren.
- Patroonherkenning toepassen.
- Test-e-mails met bijlagen verzenden.
Verschillende programmeertalen voeren verschillende scripts uit voor het testen van e-mail-API's. Overweeg tools zoals Mandrill of MailSlurp om het proces te stroomlijnen.
3. Lokaal verzenden van test-e-mails
Een andere manier om e-mails te testen is door een lokale server te configureren. Zo ontlasten QA-teams de productieomgeving van de verzendbelasting en scheiden ze tests van een echte campagne.
E-mailtests op een lokale server zijn een handige manier om ervoor te zorgen dat je niet per ongeluk een testbatch naar abonnees verzendt. Tools die je kunt overwegen zijn Mailhog of Mailcatcher.
4. Testen van e-mailafleverbaarheid en spam
Zoals we al vermeldden, helpen tests van e-mailafleverbaarheid en spam bij het bewaken van de reputatie van je domein en IP-adres en bij het ontdekken of een afzenderadres niet door internetproviders op een zwarte lijst is geplaatst.
Mail-Tester of GlockApps kan hierbij van pas komen.
Conclusie
In de QA-community krijgen e-mailtests vaak minder aandacht dan functionele tests en prestatietests. In werkelijkheid mogen QA-teams het debuggen van e-mail en het testen van de infrastructuur niet onderschatten. Probeer de in dit artikel genoemde aanpakken uit. Laat ons in het opmerkingenveld weten welke tools voor e-mailtesten jouw voorkeur hebben.
Lees meer hierover en over ander advies van QA-experts, en vergeet je niet te abonneren op de nieuwsbrief van The QA Lead om op de hoogte te blijven van het beste op het gebied van kwaliteitsengineering.
Gerelateerde lijst met tools: 10 BESTE TOOLS VOOR HET TESTEN VAN E-MAILS VOOR GEOPTIMALISEERDE BEZORGING
Stop nu niet met leren! Beluister deze podcast: GEAUTOMATISEERD TESTEN MET TESTRIGOR-CEO ARTEM GOLUBEV & PAUL GROSSMAN
