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

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

In most 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. 

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:

• Activation Link or button – Clicking on it should:
  • Take the user to respective application’s page with user account logged in
  • User’s Email account should get verified automatically if the application page is reached successfully through Email
• Duration – Check for the duration within which the link has to be clicked and verified.
  • Verify within the specified duration
  • Try to verify after the duration has passed – Account should not be activated and Email should remain unverified

#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:

• Reset password link:
  • Clicking on it should take the user to respective application’s page to reset the password
  • Some applications will ask user to answer security question before displaying reset password page, and some will have security question integrated with reset password page itself, and some will not have this feature at all
  • If user resets the password successfully, the link in the Forgot Password Email that has been received should get deactivated and non-functional
  • If user cancels the reset password flow, the link in the Forgot Password Email that has been received should remain activated
• Duration – Check for the duration within which the link has to be clicked for password reset
  • Click on the link and reset password successfully within specified duration
  • Try to click on the link after the duration has passed – Link should be deactivated and expired

#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:

• Number of Due days/Due date
  • If email notifies about a number of due days then the number should be either zero or more, zero days meant to be the current date the due is. It should not be in negative numbers. If email notifies about a Due date (Calendar date) then the date should be either the current one or the future.
• Type of action
  • Check what is the type of action required. It should very clearly state what kind of action that user has to take. Be it the bill payment, submissions, feedbacks, etc.

#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.

• Number of Overdue days
  • Check that the number of overdue days should be either one or more. It should never be zero or negative numbers
• Frequency
  • Few applications will have the provision to customize overdue emails to be sent daily/weekly/ monthly, once due date has passed, until the user completes the action. Few applications will have the standard notification to be sent just once only after the due date has passed.

#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.

• Frequency
  • Emails should be sent as per user selection for a subscription. If Daily, then subscription email should be sent just once in a day. If weekly, then once in a week. And goes on…
• Links
  • Any links in the email should navigate to the application’s respective page. If the email is for updates, then the link should redirect to the page where updates are meant to be displayed. If the email is for offers, then the link should redirect to the Offers page of the application. It depends on the type of subscription user has selected.

#6) Forms

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

• Links
  • Link in the email should redirect the user to the form submission page of the application as per the type of form user is required to submit
  • Once submitted, clicking on the link again should notify the user that form has already been submitted. It should not allow the user to re-submit the form

#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:

• Confirmation details:
  • Order number/booking number should be correct and match the number displayed in application UI. As it is the identifier to track the orders/bookings, it should be unique (to be validated in backend – DB) throughout the application. No orders/booking should share the same identifier.
  • Along with the number, it should also be validated for the type of order, user information, billing address, shipping address, and price. All the information should be exactly similar to what user has provided in the application UI.
• Links:
  • A link in the email should take a user to the order’s details page in application UI. There should be exact match between information in Email and application UI

#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

• Details
  • Check for the name of the person who provided online support. Check that the entire chat is present in the email with sender’s details for each chat entry (Person name, Date and time the chat message was sent, etc.,)

#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:

• Type of the attachment
  • Valid file types should be sent as an attachment. All the attachments being opened should be virus scanned before downloading/opening. This again can be customized at application level at the backend, like, virus scan to be performed only when downloading, only when opening, for both downloading and opening.
  • Password protected attachments should download without asking for the password. But while opening it either from Email itself or opening the downloaded copy should always ask for the password. Incorrect password entries here will be indefinite as the local copy cannot be tracked online to lock the attachment

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 3^rd 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:

• Email server is down for a long time
• The algorithm to find a short route to reach the user is not working correctly and takes very long time to reach the user, by that time maybe it would have crossed the specified time set to reach the user. This is usually called increased number of hops
• User’s email domain is down for a long time
• User’s account for the application is not activated to receive emails

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:

• Subject line
• Body of the Email
  • Contents – text of the body
  • Link name / button name
  • Copyright information
  • Customer support details

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 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 Validation is a 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 in software testing mainly in web application testing.

Let us know if you have any questions/suggestions.