We have 2 types of e-mails at the social business network company I current work with:

  • Marketing, which are pretty static and I get seldom contact to and
  • Platform interaction e-mails, like the weekly newsletter, which is very dynamic, that informs you about your profile visitors and upcoming events and more, or a less dynamic one, but important: password recovery. </p>

    What I'm doing first when the developer tells me she is finished, I send it to the Litmus.com service to get a first quick impression what happens. Litmus.com or EmailOnAcid.com, both provide you with screenshots from different clients for one e-mail you send to them. Use the watering can approach to get quick a broad idea how your e-mail behaves on different platforms and clients - shows how robust your code is. Then I run the HTML syntax checker, I prefer Firefox browser with a plugin and just the HTML code of the e-mail from a saved file: https://addons.mozilla.org/en-US/firefox/addon/html-validator/ Algorithm: HTML Tidy

    Usual I got told before by the developer where she already made some compromises, or where some effort did not solve some ugliness, yet. Since she anyways develops by verifying with Litmus.com I do it again to get the same final picture. Depending on the results I verify some unbelievable results with real devices. If the content is not static and involves dynamic input I select some minimal and some maximal input values and resend the e-mail with these settings. Our self developed templating system allows different files with made up data to feed the variables of the e-mail, and displaying the e-mail in a browser or send it to a real e-mail recipient. To get the same result, as your real recipients will get, use the same system/method to send your test e-mail as you would end up with the final live one, do not use the forwarding function of your e-mail client to show the e-mail to another person, when you want to be sure the e-mail looks the same as on your client! Forwarding is likely changing the content of the e-mail, when forwarded. There is a use case when your e-mails purpose is to get forwarded. More details: https://litmus.com/blog/when-forwarded-emails-break https://litmus.com/blog/preventing-unsubscribes-in-forwarded-emails

    After that I select some mobile devices; one iOS, one Android, to interact with the e-mail, click it, use horizontal/vertical switching, load pictures, when previous they are not loaded. Checking what it looks like without loaded pictures is an important point, there are many clients who prevent loading pictures per default. <picture w/o pictures> As always with mobile, check load behaviour on slow networks and check if you can reduce the byte size of the e-mail itself and the loaded pictures to make a smooth experience for your users. There also comes the aspect of deciding what is more important: the size of the e-mail code, or the pixel perfect visualisation in as many clients as possible. The more clients you want to have perfect, the bigger and complex gets the code. I prefer a not so perfect e-mail, that is small and does contain a code path that is ok with most clients. You are used to working on a fast company network, but take into account, especially with mobile devices where the e-mail might be received: On a slow network, in the underground, at the end of the month, when you reached the limit of your fast transfer quota. </p>

    Then I send it to some webmail accounts that are not included in Litmus.com, but have a relevant coverage for our target recipients and check what it looks like there. Famous is the T-Online e-mail webfrontend, the layout of the e-mail usually breaks there when some closing tags are mixed up or missing, where as every browser is more robust displaying the HTML of the e-mail than via that webfrontend. While doing that I watch the used header data, sender address, reply to, subject, if all complies to the specification for that e-mail and if the pre-header text is reasonable in length.

    Since we use a templating system I do that first in one of the major languages: german or english - take a look on a complete mail for the other one and for the rest I look for the status of the new translated strings in the translation database. It might be worth to consider, that some translations will have significant longer strings, like french - watch if it does not break some layout where the e-mail was expected to have less text.

    Links are a special case for us, we route every link from our e-mails through one system and decide there where to finally redirect to. Checking the link targets on desktop is quite easy, you just expect the browser to open it, on mobile we are two fold, I expect most of the links of an e-mail open in our mobile app if it is installed. So I have to check we end in both cases either in the respecting section in the mobile app, so opening the app with the link is not enough it also has to be somewhere deep navigated into it. The links in the e-mails also provide us with important feedback: For measuring the usage of an e-mail we have a tracking code on every link - so there should be no link without tracking in the e-mail.

    Depending on your use case, get some more testing ideas, look at http://apps.testinsane.com/mindmaps/E-mail-related-tests-for-web-applications a mindmap I found, or to get my testing ideas, via auto reply, send an e-mail to emailmind.map @ gmail.com, or look at a presentation by Santhosh Tuppad http://tuppad.com/blog/wp-content/uploads/2013/10/Email-testing-for-web-applications-by-Santhosh-Tuppad.pdf or my one (in german): https://de.slideshare.net/secret/yGjgY0oY6vuFTr.

    The next part will close the frontend topic, with rollout to live and a small self made test system idea: https://einmanaleiki.de/testing-e-mails-more-frontend-part-3-32