Email Validation Testing: How to Test the Email Functionality of an Application

Today’s tutorial is all about testing email functionality of any application.

In most of the web and mobile applications, validating Email feature is considered as one of the most important parts of testing, to assure quality in Email component as well along with other components of the system.

Emails triggered under different scenarios are considered to be validated by checking for all its components which includes a template of Email, Links/buttons in the Email, From, To, Cc, Bcc fields, Attachments, Content as per Email notification, etc. 

What You Will Learn:

Why do we need Email Testing?

Each component in the system (Web/Mobile applications) may have different purposes to send Emails. Integration between the component(s) and Email plays a vital role in reaching end-user with proper notifications. Any negligence when we are validating this feature will lead to misunderstandings, bad name on the customers, hacking, etc.

For example, imagine a situation where a user has received an email to reset the password. What if the Reset password link/button or the URL provided to copy paste in a browser is not functioning? The only option left here is to contact customer support, which may become a tedious thing or imagine a situation where the user keeps receiving an Email daily regarding due date for bill payment from 10-15 days earlier or receives a reminder after the due date is passed. – Irritating isn’t it??

There are a lot many scenarios where Emails have become an integral part of our life as they are meant to keep the user up-to-date with precise information.

Common Real-time Scenarios and Validation points for Emails

Validation points in testing Emails varies from type to type, and again from application to application. Commonly all Emails should be validated for the template (which includes application logo, application name, Addressing the user, Footer contents – Copyright, Customer support details), date and timestamp for different time zones.

Here we will discuss some common types of Email that almost everyone is aware of (all the validation points given below are the basic check that the tester has to perform while testing Emails of the application).

#1) Activation Emails

When a user registers to an application for the first time, he/she needs to activate the account by clicking on the activation link sent in Email. This also verifies the user’s given Email address is valid and accessible.

Validation points are as below:

#2) Forgot Password Emails

When a user forgets the password to login to the application, forgot password flow can be performed to receive an Email with link to reset the password (feature varies from application to application. This is the general one).

Validation points are as below:

#3) Due Date Notifications

This is to remind the user about the action to take in a particular number of days. This usually is the bill payments, taking action on pending items (example: accepting or rejecting the invite to some event in a particular number of days, submitting forms, etc..).

Validation points are as below:

#4) Overdue Notifications

This is to inform the user about due date has passed. This usually is to inform the user that he/she has not taken action on the items within due date.

#5) Subscriptions

This varies as per user requirements. The user can select one among the following Daily, Weekly, Bi-Monthly or Monthly subscriptions. This will usually be for newsletters, updates, offers, etc.



#6) Forms

Emails here intends user to provide feedback through forms/link to forms. Validation points are as below:

#7) Confirmation Emails

Emails here are to notify the user about the confirmation of the action taken. This usually is the reservation confirmations, order confirmations, query confirmations, etc..

Validation points are as below:

#8) Chat Transcript

Here, a user receives the entire chat transcript as Email. This usually be once the Live Chat with Customer support is ended.

Validation points are as below

#9) Emails with attachment

The user receives Emails with attachment. Attachments can be password protected/unprotected. This usually be the statements from financial domains, End User License Agreement for reference, Terms & Conditions for reference, etc., this again varies from application to application.

Validation points are as below:

Types of Emails

Email type can be either HTML (colorful and attractive to the users, which interest’s user to read the Emails fully) or Plain Text (just a text).

HTML is most preferred ones and usually set as default in almost all applications at the backend. If required, applications can opt to send Plain text emails to users, again this requires changes at the backend.

Emails Trigger points:

Emails can be sent either immediately or as summary/batch. Immediate emails are triggered by the action of the user. These will be usually activation emails, reset password emails, chat transcriptions, confirmation emails, etc., i.e., Summary/batch emails are triggered based on the settings at the application’s backend.

Email Trigger points will be defined to trigger at the specific point of time (for example 3rd day of every week at 12:00 AM). These will usually be the statements from financial domains (Bank statements), due date notification for bills, overdue notifications, subscriptions, etc.,

Bouncebacks:

It is a very common scenario that emails bounce when they are sent to invalid email address. Usually, the email address that is deactivated/no longer in use, and does not exist at all – are the candidates that bounce back.

The server usually tries for a specified number of times to send Email to the intended address. When it does not reach the intended email address, then it gets bounced back and will make an entry in the server for its failure. There will be a different server to maintain these type of activities and are usually called a bounce back servers. There could be several reasons for an email to fail by reaching its user.

Below are few other points for failure:

Localization Scope for Emails testing

When the application supports multiple languages, then the support should extend for Emails as well.

All the Emails sent should be in the user-profile language. If a user has set English as the profile language, then all the emails sent to him/her should be in English. If user’s profile language is French, then all the emails sent to him/her should be in French. User profile language can be one-time settings or can be changed as and when required, which depends on application’s settings.

Email should be sent in the language that the user has at the point it is triggered.

Common validation points for localization testing the Emails are as below:

Standard/Customization of Emails

Emails can be customized at the backend.

For example, few applications support the user to customize Emails when they are being sent. The user can change here the Subject line and/or body of the email to his convenient or for the purpose to recognize easily. In this case, thorough testing has to be done by the testing team as the chances of intruding is high.

Testing has to be performed for injections – send HTML code, Java code, SQL, etc. All these should fail in order to increase security levels. If the application does not support customization of emails, then all the emails sent will follow standard subject/body as set by an application.

Conclusion

Testing Emails is an important activity as most of the components of the application are integrated with this functionality.

It should be the entire team’s support and effort to completely test the email functionality of the application. This should be well-planned much before the actual testing starts and should go hand-in-hand while testing each component/associated component.

Email Testing should have the separate test cases written for each Email type covering all the aspects to test. This should be carried out in all types of testing Regression testing, Adhoc testing, Localization testing, UAT testing, and Production testing.

Anything that goes wrong in Email in real-time, will leave a bad impression on the application, customers, and eventually, it carries forward to testers of that application. So Email Validations is very crucial and much-required activity in Software testing.

About the author: This post is written by STH author Nandini K. She is having 7+ years of experience into software testing mainly in web application testing.

Let us know if you have any questions/suggestions.