Pitäisikö laadunvarmistajien välittää sähköpostitestauksesta?

By Dmytro Zaichenko

Kyllä, laadunvarmistajien tulisi välittää sähköpostien testauksesta. Tässä artikkelissa selitetään syyt, testattavat elementit ja se, miten sähköpostien testaamisesta voi tehdä vaivatonta. Ensinnäkin sinun on ymmärrettävä, minkälaisesta sähköpostien testauksesta puhumme. Yleisesti sähköpostien testauksella tarkoitetaan muutamia menetelmiä sähköpostien tarkistamiseen ennen niiden lähettämistä. Sähköpostimarkkinoijille kyse on enemmän sisällön analysoinnista ja kampanjoiden A/B-testauksesta. Sovellusten parissa työskenteleville kehittäjille ja laadunvarmistajille, joiden […]

Kyllä, laadunvarmistajien tulisi välittää sähköpostien testauksesta. Tässä artikkelissa selitetään syyt, testattavat elementit ja se, miten sähköpostien testaamisesta voi tehdä vaivatonta.

Ensinnäkin sinun on ymmärrettävä, minkälaisesta sähköpostien testauksesta puhumme.

Yleisesti sähköpostien testauksella tarkoitetaan muutamia menetelmiä sähköpostien tarkistamiseen ennen niiden lähettämistä. Sähköpostimarkkinoijille kyse on enemmän sisällön analysoinnista ja kampanjoiden A/B-testauksesta. Sovellusten parissa työskenteleville kehittäjille ja laadunvarmistajille, joiden sovellukset lähettävät tapahtumapohjaisia sähköposteja, sähköpostien testaus tarkoittaa laajempaa toimenpiteiden kokonaisuutta – HTML-koodin analysoinnista sähköpostien toimitettavuuden varmistamiseen. 

Käsittelen seuraavat aiheet:

Aloitetaan sähköpostien testauksen tärkeydestä laadunvarmistajille.

Testausta ei voi laiminlyödä: tässä syy

Tilastojen mukaan yli 300 miljardia sähköpostia lähetetään ja vastaanotetaan päivittäin. On vaikea kuvitella, kuinka paljon yritykset lähettävät päivittäin virheellisiä sähköposteja. On kuitenkin kiistatonta, että tällaiset viestit vaikuttavat brändin maineeseen ja heikentävät käyttökokemusta.

Tästä syystä sähköpostien virheenkorjaus on kehitys- ja laadunvarmistustiimin vastuulla, jotta markkinointitiimi voi käynnistää asianmukaisen kampanjan.

Tämän vaiheen ohittaminen johtaa kolmeen merkittävään kielteiseen seuraukseen:

Renderöintivirheet = huono käyttökokemus 

Valitettavasti kaikki sähköpostiohjelmat eivät tue HTML:ää ja CSS:ää samassa määrin. Esimerkiksi Outlook tai muiden kuin Google-tilien Gmail-sovellus eivät renderöi taustakuvia. 

Samoin sähköpostiohjelmilla on usein erityisiä sähköpostien suunnittelua koskevia ohjeita – Yahoo Mail pakottaa käyttämään marginaaleja, kun taas Gmail leikkaa yli 102 kilotavun pituiset viestit. 

Koska suunnittelijat eivät välttämättä huomioi renderöintistandardeja useiden sähköpostiohjelmien laajassa joukossa, testaajan tehtävänä on täyttää kaikki vaatimukset. 

Siksi kampanjoiden testaamiseen kannattaa keskittyä ennen niiden jakamista käyttäjille. Muuten käyttäjä saattaa nähdä viestin katkaistuna, asettelultaan siirtyneenä, reagoimattomana tai sisältöä ei välttämättä tueta. Tämän seurauksena huono käyttökokemus on taattu, ja on suurempi todennäköisyys, etteivät asiakkaat palaa. Jos koko kampanja sisältää rikkinäisiä sähköposteja, tilanne on turhauttava.

Toimitettavuus kärsii

Luotettavan yhteyden varmistaminen sovelluksen sisäisten sähköpostien ja loppukäyttäjien välillä on ratkaisevan tärkeää suurten käyttäjämäärien tukemiseksi. Koska monet tiimit käyttävät sähköposti-ilmoituksia salasanojen jakamiseen ja yhteisölle tuotepäivityksistä ilmoittamiseen, tilaajien tavoittamatta jääminen on harmillista. 

Sähköpostimarkkinoinnissa sähköpostien toimitettavuus on ratkaiseva tekijä, joka määrittää, voiko käyttäjä vastaanottaa tärkeän viestisi. Kampanjan toimitettavuusasteeseen vaikuttavia tekijöitä on paljon: roskapostiksi ilmoitettujen sähköpostien määrä, käyttäjien vuorovaikutus viestien kanssa, palautusprosentit ja muut tekijät. 

Sähköpostiprosessin infografiikka
Ennen kuin sähköpostit toimitetaan, niiden on läpäistävä luotettavuustarkistukset. Jos olet varmistanut sähköpostien toimitettavuuden, mikään este ei vaikuta siihen, että viestisi päätyy vastaanottajan postilaatikkoon (Lähde).

Sujuvan toimitettavuuden rakentaminen vaatii paljon työtä, ja se on yleensä insinööritiimin vastuulla. Laadunvarmistajan on tiedettävä, milloin ja kuinka monta tapahtumapohjaista sähköpostia verkkosivusto tai sovellus lähettää. Toisaalta kaiken vaivannäön hukkaan heittäminen on yllättävän helppoa – muutama rikkinäinen linkki tai epäonnistunut roskapostitarkistus riittää romuttamaan kuukausien työn. 

Toimitettavuuden testaaminen on keino estää tällaiset turhauttavat takaiskut, sillä sen avulla laadunvarmistustiimi voi: 

  • välttää roskapostiloukkuja (Internet-palveluntarjoajien eri puolille verkkoa sijoittamia väärennettyjä sähköpostiosoitteita, jotka robotit usein löytävät ja jotka lisätään tilaajakantaan) 
  • selvittää, mitkä sähköpostiinfrastruktuurin elementit on määritetty väärin (IP-osoite, DNS-tietueet, sähköpostin todennustietueet jne.)
  • varmistaa, ettei sisällössä ole roskapostin laukaisevia tekijöitä

Jos laadunvarmistaja tai kehittäjä jättää roskapostitarkistukset ja toimitettavuuden testaamisen huomiotta, kampanjat tai tärkeät sähköpostit eivät saavuta loppukäyttäjää. Miten käyttäjä voi palauttaa salasanansa tai saada rekisteröitymislinkin, jos testaamaton sähköposti päätyy jonnekin verkon sisälle? Toimittamattomien sähköpostien vuoksi yritys voi kärsiä asiakasmenetyksistä ja muista liiketoiminnan epäonnistumisista.

Maine kärsii

Nyt erittäin personoidut sähköpostit ovat vahva trendi. Dynaamisia tunnisteita täynnä olevia viestejä lähetettäessä asiat kuitenkin karkaavat usein käsistä. 

Vastaanottajille ei ole mitään uutta siinä, että he saavat kirjeitä, joissa on väärät nimilaput tai aiherivejä, kuten ”Hei, [username]”. Brändeille pienetkin huolimattomuusvirheet romahduttavat koko kampanjan konversiot ja heikentävät brändien mediasuhteita. Syy on yksinkertainen: ensivaikutelman tekemiseen ei saa toista mahdollisuutta. Jos mokaat kerran, tilaajat todennäköisesti merkitsevät kirjeen roskapostiksi tai jättävät negatiivista palautetta. Tällöin brändi yhdistetään rikkinäisiä sähköposteja lähettäviin tahoihin vain siksi, että joku ohitti HTML/CSS-testauksen.

Aiheeseen liittyvä lukeminen: NEGATIIVISEN TESTAUKSEN MYÖNTEISET TULOKSET

Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

QA-sähköpostitestauksen 4 kipukohtaa (+ tapoja kiertää ne)

Olemme hahmotelleet neljä merkittävää haitallista vaikutusta, joita virheellisten sähköpostien lähettäminen aiheuttaa. On aika ymmärtää niiden testaajien kipukohdat, jotka kamppailevat urheasti sähköpostien virheenkorjauksen kanssa. 

Emme voi emmekä halua tuomita. Sähköpostitestauksen työnkuluissa oli vuosien ajan paljon puutteita, jotka tekivät prosessista liian manuaalisen, hitaan ja tehottoman.

On olemassa toimivia kiertotapoja, jotka poistavat testauksen kipukohdat. Katsotaan, miten ärsyttävimmistä hankaluuksista selvitään. 

1. Testisähköpostit päätyvät oikeille käyttäjille

Tämä ärsyttävä ongelma johtuu siitä, että QA-tiimit käyttävät tuotantotunnuksia testisessioiden suorittamiseen. Tämän seurauksena raja on helppo ylittää ja testiviesti voidaan vahingossa lähettää tilaajalistalle. 

Lisäksi tuotantopalvelimen käyttäminen testien suorittamiseen kasvattaa verkkotunnuksen lähetysmääriä ja heikentää verkkotunnuksen mainetta. 

On helppo varmistaa, ettet lähetä sähköpostia oikeille käyttäjille vahingossa, kunhan käytät erillistä testiympäristöä. Sähköpostien turvalliseen testaamiseen on kaksi tapaa:

  • Kehitysympäristön testaus API-integraation avulla
  • Työkalujen käyttäminen, jotka jäljittelevät oikeiden SMTP-palvelinten toimintaa ja joiden avulla voidaan tarkistaa yleiset SMTP-portit ja muut infrastruktuurin osat. 

2. Heikko toimitettavuus (tai päätyminen roskapostikansioihin)

Jos esikatselusähköpostisi päätyvät Roskaposti-kansioon, se ei välttämättä ole hälytysmerkki. Ennen kuin hälytät markkinointitiimin ja tarkistat infrastruktuurin uudelleen, sulje pois seuraavat vaihtoehdot:

  • Esikatselusähköpostissasi on edelleen täytetekstiä. Kun lähetät testisähköposteja, varmista, että viestin sisältö on täsmälleen sama kuin käyttäjän näkemä sisältö. ”Lorem Ipsum dolor” -tekstin kaltaiset jäänteet aktivoivat roskapostisuodattimet ja romahduttavat testisähköpostin toimitettavuuden. 
  • Et avaa omia testisähköpostejasi. Jos käytät omaa osoitettasi sähköpostien testaamiseen, internetpalveluntarjoajat merkitsevät viestit merkityksettömiksi ja alkavat lähettää niitä roskapostiin, ellet ole vuorovaikutuksessa niiden kanssa. 
  • Lähettäjän ja vastaanottajan osoitteet täsmäävät. Sähköpostiohjelmat edellyttävät sähköpostien onnistuneen toimituksen varmistamiseksi, etteivät lähettäjän ja vastaanottajan osoitteet ole sama postilaatikko. Kun siis lähetät testiviestin itsellesi, valitse eri sähköpostiosoite kuin se, josta lähetät testin. 
  • ”Peruuta tilaus” -linkki puuttuu. Viesteillä, joiden alatunnisteessa ei ole ”Peruuta tilaus” -linkkiä, on 99,9 %:n todennäköisyys palautua lähettäjälle tai joutua merkityksi roskapostiksi. 
Peruuta tilauksen lisäämisen kuvakaappaus
”Peruuta tilaus” -alatunnisteen lisääminen antaa tilaajille mahdollisuuden poistua listalta estämättä lähettäjää ja suojaa yrityksen mainetta (Lähde).

3. Heikko renderöinti ja eri laitteiden välinen responsiivisuus

Toinen QA-tiimien kohtaama este on sen havaitseminen, että viestit näytetään eri tavalla eri sähköpostiohjelmissa tai laitteilla. Jos tämä koskee testierääsi, tässä on muutamia sähköpostiohjelmakohtaisia renderöintiin liittyviä seikkoja, joiden avulla sinun tulisi tarkistaa sähköpostin sisältö eri ympäristöissä:

Gmail:

  • Kuvat ovat oletusarvoisesti tuettuja. 
  • Yli 102 kB:n kokoiset sähköpostit leikataan automaattisesti. 
  • <style>-tunniste sijoitetaan sähköpostin head-osioon. 
  • Sähköpostit skaalataan automaattisesti iPhoneissa (kuvat näyttävät olevan epäkeskellä, joten <body>-elementtiin kannattaa lisätä ”padding:0”. 
  • Tekstin vähimmäiskoko on leipätekstille 10,5 pt ja otsikoille 16,5 pt, jotta luettavuus älypuhelimissa säilyy. 

Outlook:

  • Ei tukea taustakuville. 
  • Ei tukea vuorovaikutteisille elementeille, kuten lomakkeille tai valintaruuduille. 
  • Ei tukea HTML5-videoille tai GIF-kuville. 
  • Rajoitettu tuki sisäkkäisille elementeille. 

4. Tehoton testaus

2000-luvulla sähköpostien testaus oli manuaalista, staattista ja työlästä. Testausryhmien piti luoda sähköpostit alusta alkaen ja lähettää ne testiosoitteisiin. Hyvä uutinen on, että nykyään useimmat näistä vaiheista voidaan automatisoida helposti. 

Tässä on muutamia työkaluja, joiden avulla laadunvarmistusryhmät käyttävät vähemmän aikaa yksittäisten sähköpostielementtien testaamiseen:

  • Sähköpostin esikatselu: Litmus
  • Sähköpostipalvelimet: GMass
  • Sähköpostin ohjelmointirajapinta: Mailosaur
  • Roskapostitarkistus: SpamAssassin
  • Sähköpostien toimitettavuus: Mail-Tester
  • HTML-tarkistus: HTML Email Check
  • Selainten automatisointijärjestelmä: Selenium

Jos tarvitset täyden pinon testausratkaisun, jonka avulla voit testata kaikki sähköpostien tekniset osa-alueet, kuten SMTP:n, ohjelmointirajapinnan sekä HTML:n ja CSS:n, suosi yhteistyöhön sopivia työkaluja, kuten Mailtrapia. 

Sähköpostien testaus on vain yksi laadunvarmistuksen osa-alue. Tutustu kattavaa laadunvarmistusta varten oppaaseemme parhaista ohjelmistojen testaustyökaluista.

Tärkeimmät testattavat sähköpostielementit

Nyt kun tiedät, ettei sähköpostien testaamista voi sivuuttaa, ja ymmärrät, miten laadunvarmistusryhmien kohtaamat tärkeimmät haasteet voidaan ratkaista testejä suoritettaessa, on aika luoda vaiheittainen testausstrategia, joka varmistaa sähköpostiesi hyvän toimitettavuuden ja moitteettoman renderöinnin. 

Tässä ovat tärkeimmät sähköpostitestien tyypit, joita laadunvarmistusryhmän tulisi suorittaa.

1. SMTP:n valvonta

SMTP-virheet ovat yleinen syy sähköpostien toimitettavuusongelmiin tai koko sähköpostiinfrastruktuurin toimintahäiriöihin. Tässä ovat ongelmat, joita laadunvarmistajien tulee tarkkailla:

  • Palomuuri estää viestinnän.
  • Palvelimen vastaus kestää liian kauan. 
  • SMTP-palvelin muodostaa yhteyden väärällä isäntänimellä. 
  • SMTP ei tue annettuja komentoja. 

SMTP-arvioinnin tehostamiseksi laadunvarmistusryhmät käyttävät siihen tarkoitettuja työkaluja: Web Biz tai Wormly.

2. Sähköpostin ohjelmointirajapinnan testaus

Ohjelmointirajapinnan testauksen avulla kehittäjät voivat testata sähköposteja poistumatta kehitysympäristöstä. Ohjelmointirajapintoja käyttämällä voit:

  • Automatisoida prosessin mahdollisimman pitkälle.
  • Hakea sähköposteja koodissa. 
  • Poimia testisähköpostin sisällön ja tarkistaa sen. 
  • Soveltaa hahmontunnistusta. 
  • Lähettää testisähköposteja liitteineen. 

Eri ohjelmointikielet suorittavat erilaisia komentosarjoja ohjelmointirajapinnan sähköpostitestaukseen. Prosessin tehostamiseksi voit harkita esimerkiksi Mandrillin tai MailSlurpin käyttöönottoa. 

More Articles

3. Testisähköpostien lähettäminen paikallisesti 

Toinen tapa testata sähköposteja on määrittää paikallinen palvelin. Näin laadunvarmistusryhmät vähentävät tuotantoympäristön lähetyskuormaa ja erottavat testauksen todellisesta kampanjasta. 

Sähköpostien testaaminen paikallisella palvelimella on hyödyllinen tapa varmistaa, ettet lähetä testierää vahingossa tilaajille. Huomionarvoisia työkaluja ovat Mailhog tai Mailcatcher. 

4. Sähköpostien toimitettavuuden ja roskapostin testaus

Kuten mainitsimme, sähköpostien toimitettavuuden ja roskapostin testaus auttaa hallitsemaan verkkotunnuksesi ja IP-osoitteesi mainetta sekä selvittämään, ettei Internet-palveluntarjoaja ole lisännyt lähettäjän osoitetta estolistalle. 

 Mail-Tester tai GlockApps voi olla hyödyllinen.

Yhteenveto

Laadunvarmistusyhteisössä sähköpostien testaus jää usein toiminnallisen ja suorituskyvyn testauksen varjoon. Todellisuudessa laadunvarmistusryhmien ei pitäisi aliarvioida sähköpostien virheenkorjausta ja infrastruktuurin testausta. Kokeile tässä artikkelissa mainittuja lähestymistapoja. Kerro kommenttiosiossa, mitä sähköpostien testaustyökaluja sinä suosit. 

Lisätietoja tästä ja muista QA-asiantuntijoiden neuvoista saat tilaamalla The QA Lead -uutiskirjeen, jotta pysyt ajan tasalla laadun suunnittelun maailman parhaista käytännöistä.

Aiheeseen liittyvä työkaluluettelo: 10 PARASTA SÄHKÖPOSTIN TESTAUSTYÖKALUA OPTIMOITUUN TOIMITUKSEEN

Älä lopeta oppimista vielä! Kuuntele tämä podcast: AUTOMAATTINEN TESTAUS / TESTRIGORIN TOIMITUSJOHTAJA ARTEM GOLUBEV & PAUL GROSSMAN

Dmytro Zaichenko
Dmytro Zaichenko is a Digital Marketing Specialist at Mailtrap, an email sandbox service. Apart from collaborating with the dev team and networking, he's passionate about writing and has 6+ years of experience in producing engaging content.

You may also like