Email testing during user acceptance testing (UAT)

13th Jun 2023

Share this article:

What is user acceptance testing?

User Acceptance Testing (UAT) is often the last phase of testing for a piece of software. Otherwise known as beta testing, or end-user testing, it is where the intended users test out the software prior to release.

Generally, real users of the software, or representatives of them (for example, the business team who has paid for the development of the software), use the system as it would be used in reality and make sure that the software matches the business requirements and is fit for purpose. This could cover checking for bugs that have been overlooked as part of the development process, through to checking content and on to spotting anything that does not match the desired behaviour.

UAT is usually performed using a different environment from the live system. However, to get the best out of UAT, its environment should match the production system as closely as possible, minimising the chance of missing bugs due to unrealistic data or infrastructure.

The outcome of UAT is a list of issues/bugs categorised by their severity. These are then reviewed with the developers and the business and prioritised. Sometimes this is sufficient to prevent the release of the software. At other times, it's acceptable to release the software and then fix the issues in subsequent releases.

Why would you care about email testing in UAT?

Nearly all software systems, especially in business, send emails as part of their operation. For example, confirmation emails, forgotten password or overdue notifications. Usually, sending email is a critical part of the system''s functionality so it's important to test that the functionality works as expected. Sometimes, receiving an email is just a pre-requisite part of setting up a user account and, where the tester needs lots of accounts, it's important to make that as easy as possible.

During UAT users will want to see when emails are triggered, that their content is as expected and that any links they contain also work as expected.

As mentioned, during UAT it's important that the environment is as life-like as possible. This means you want to let testers use realistic data and to be able to create as many different test scenarios (and accounts) as possible. What you don't want, though, is for those testers to accidentally send test emails/notifications to real users.

Picture of Tweet from HBO apologising for mass email

It's important the email functionality works for testing purposes but does not actually send emails.

Email sandboxing to the rescue

In order to solve this problem, you can make use of an email sandbox server. This server communicates over standard email protocols but does not actually send real emails on to recipients. Instead, the emails are stored on the server so that users can look at the emails the system would have sent without actually sending them.

There are various software tools that will perform this function, some of them open source, others proprietary.

At Imitate Email, we've built an email sandbox server designed specifically for supporting user acceptance testing. As a software development consultancy, we're always doing demos to our end clients and asking them to undertake user acceptance testing as new features are developed. To make that easy for them, we didn't want to make them log in to a separate tool. We wanted to make the test email visibility an integrated part of their application so that they can easily see when emails are sent and then inspect them without leaving the application. This keeps their focus on the testing of their application, not elsewhere.

How does Imitate Email achieve this?

Imitate Email provides a sandbox email server that speaks the standard email protocols: SMTP, IMAP and POP3. That makes sending emails to it very easy. Simply update your SMTP settings to match our SMTP server and all your emails will be sent to us instead of to real people. If your software is bespoke, this is usually very easy for developers to set up by changing their configuration. For 3rd party tools, many can be customised to send emails using a different email provider.

To view the test emails, Imitate Email provides an embedded email viewer that can be added to a web application using a single line of JavaScript. For developers, this is the end of the story as they can log in using their account details and see test emails inside the application that they're building.

For user acceptance testing, it's often not practical to set up accounts for your 3rd party testers and, frankly, it's not a great user experience to mandate that they log in to a separate tool to undertake the UAT.

Imitate Email provides "login-less authentication". This lets the application under test tell Imitate Email the details of the user that is logged in, removing the need for them to identify themselves. We do this using a secret key that is shared between Imitate Email and your application.

Finally, there's often multiple people doing UAT at the same time and, for simplicity, they should only see those emails that they're generating. This is made more difficult by the fact that each tester will be creating multiple test accounts as they go. As a result, a single tester will want to see emails to multiple recipients. To solve this, it's possible to send a specific header inside the email that tells Imitate Email who the test email is intended for.

See it in action

Next steps

Getting started with Imitate Email is easy (and free): You can sign up using just email or a social account.

For details on setting up for UAT with login-less authentication and user idenfication you can view our team email viewer docs