Email Validation Testing: Test 9 Different Types of Emails

This tutorial is all about testing the email functionality of any application:

In most web and mobile applications, validating the email feature is considered one of the most important parts of testing to ensure quality in the 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. Let’s look at it in detail.

Email Validation Testing

Why we need Email Testing

Each component in the system (Web/Mobile applications) may have different purposes to send Emails. Integration between component(s) and email plays a vital role in reaching end-users with proper notifications. Any negligence when we are validating this feature will lead to misunderstandings, bad names of 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 the due date for bill payment from 10-15 days earlier or receives a reminder after the due date has passed. – Irritating isn’t it??

There are a lot of 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 vary 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 emails that almost everyone is aware of (all the validation points given below are the basic checks 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 that 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 their respective application page with the user account logged in
  • User’s email account should automatically be verified 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
  • Trying 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, a forgot password flow can be performed to receive an email with a 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 their respective application’s page to reset the password
  • Some applications will ask users to answer security questions before displaying the reset password page, and some will have security questions integrated with the reset password page itself, and some will not have this feature at all.
  • If the user resets the password successfully, the link in the Forgot Password email that has been received should be deactivated and non-functional
  • If the 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 your password successfully within the 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 actions to be taken in a particular number of days. This usually involves bill payments, taking action on pending items (example: accepting or rejecting an invite to an event for a particular number of days, submitting forms, etc..).

Validation points are as below:

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

#4) Overdue Notifications

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

• Number of Overdue days
  • Check that the number of overdue days should be either one or more. There 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 the due date has passed, until the user completes the action. Few applications will have the standard notification to be sent only once after the due date has passed.

#5) Subscriptions

This varies as per user requirements. Users 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 the subscription email should be sent just once a day. If weekly, then once a week. And goes on…
• Links
  • All links in the email should navigate to the application’s respective page. If the email is for updates, then the link should redirect you to the page where updates are meant to be displayed. If the email is for offers, then the link should redirect you to the Offers page of the application. It depends on the type of subscription the user has selected.

#6) Forms

Emails here are intended for users to provide feedback through forms/links 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 the user is required to submit
  • Once submitted, clicking on the link again should notify the user that the 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 is usually for reservation confirmations, order confirmations, query confirmations, etc..

Validation points are as below:

• Confirmation details:
  • The order number/booking number should be correct and match the number displayed in the 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 the user has provided in the application UI.
• Links:
  • The link in the email should take the user to the order details page in the application UI. There should be an exact match between the information in the email and the application UI.

#8) Chat Transcript

Here, the user receives the entire chat transcript as an email. This usually happens once the Live Chat with Customer support has 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 the sender’s details for each chat entry (Person’s name, Date and time the chat message was sent, etc.,)

#9) Emails with attachment

The user receives emails with attachments. 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 attachment
  • Valid file types should be sent as an attachment. All attachments being opened should be virus scanned before downloading/opening. Again, this can be customized at the application level at the backend, like, a virus scan to be performed only when downloading, and only when opening, for both downloading and opening.
  • Password protected attachments should be downloaded without asking for a password. But while opening it either from the email itself or opening the downloaded copy should always ask for the password. Incorrect password entries here will be indefinite as local copies 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 the most preferred one and is usually set as the 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 a summary/batch. Immediate emails are triggered by the action of the user. This will usually include 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 as triggers at a specific point in time (for example 3^rd days of every week at 12:00 AM). These will usually be statements from financial domains (Bank statements), due date notifications for billing, overdue notifications, subscriptions, etc.,

Bounce backs:

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

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

Below are a 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 an increased number of hops
• User’s email domain has been down for a long time
• User’s account on the app is not activated to receive emails

Localization Scope for Emails testing

If the application supports multiple languages, then the support should be extended for emails as well.

All emails sent should be in the user’s 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 the user’s profile language is French, then all the emails sent to him/her should be in French. User profile language can be a one-time setting or can be changed as and when required, which depends on the 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 of the emails are as given 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 from the backend.

For example, few applications support the user to customize Emails when they are being sent. The user can change the Subject line and/or body of the email here for his convenience or for the purpose of recognising easily. In this case, thorough testing has to be done by the testing team as the chances of intruding are 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 the 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 aspects of the 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 will carry forward to testers of that application. Therefore, 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 in the comments section below. We would love to hear from you.