Testing e-mails ✉ ✓, more Frontend. Part 3
When I know the e-mail itself looks ok, I go to a complete testing system and try to trigger the e-mail from there, with real data and think about special cases, like what happens if some optional data is there or not. There I look into the logs, if some errors happened, because of some naming mismatch in the payload that should trigger the e-mail, or if some expected non optional data is missing.
When this is all ok, the e-mail is put to the live system and sometimes ramped up just to a part of users for some time in these stages:
There you can see then all kinds of problems
Some good about our system, when an error happens the e-mail is not send - so mostly no user facing issues :-) </p>
Thats roughly the process for every new e-mail.
To build yourself a quick local testing system you could take a shortcut with some assumption: - the default e-mail client of every platform uses the same HTML rendering engine as the default browser. Put the HTML somewhere accessible on a web server and visit with
The most obvious issues are catched and are reproducible by this - which is also an important topic for the developer and you to analyse issues. </p>
If you have the HTML of your e-mails accessible it's also possible to do an easy first regression testing, when there is a change in a component of an e-mail that is used among all your e-mails: https://github.com/BBC-News/wraith It compares screenshots of the same web path on different hosts. I like it, because if you have to identify changes in 100 types of e-mails, it identifies changes easily. For me it solves the job: Frontend-dev: 'Hey tester, I just changed our button code a little, that is used in every e-email, it should not change the layout...'
In the next part on a part of the backend, how to track and analyse e-mail interactions: https://einmanaleiki.de/testing-e-mails-backend-part-4-33