First, we look at a simple use case of Testing 2 Factor Authentication via Mail Box. 

Then we go on to understand what Email Validation is and its use cases.



Email-based OTP Verification in Testsigma


Does your application have Email based 2 step authentication and you are not able to test it with traditional testing frameworks?


Testsigma makes it very easy to retrieve OTP from an email address and insert it into the test case to perform the authentication swiftly and securely. 


Your data is secure with us. 


Follow the 5 step tutorial to understand how to write a test case for Email-based authentication.



Step 1: Ensure that you have a good understanding of the authentication feature on your application 


Know the steps to enter an email address and know exactly what type of OTP is generated.


For example: Does your feature generate a 4 digit OTP or a 5 digit OTP? Does your OTP come with alphanumeric characters?


Understanding this is necessary to write the regex function.


Step 2: Log in to Testsigma, create a new test case. 





Step 3: Add the following steps using the NLP based approach






  • First Navigate to the link where the Email OTP generation feature is available. 


  • Enter the email address that has been linked to your testsigma account specifically for testing this feature. This is not the account using which you log in. 


Where can you get the email ID?


A separate email address is provided to you. This email address is available in the NLP used in step 4, in the drop-down of the test step. Choose the email id from the drop-down. 

 

You can also easily find this by navigating to the “Settings” menu → Mail Boxes as shown in the screenshot below.




  • Use the NLP “Enter test data in the email textbox with label text ” to enter the Email address and the label of the email address field to let the test know where to enter the email.

  • Now use the NLP, “Click on UI identifier”, to click on the element/button that initiates the OTP transfer to the specified email address.


  • Use NLP, “Enter test data into UI identifier”

    • Select the test data placeholder, delete it, click on “Functions” from the drop-down menu

    • In the functions window, type “OTP”, choose the function “MailBoxFunctions:: getEmailOTP”

      • In the regex field, enter \d{4,8} → This extracts all OTPs which are numbers and between 4 and 8 digits in length

      • Choose the email address from the drop-down

      • Provide a timeout 

      • Click create



  • Use NLP, “Click on UI identifier” to click on the element that submits this OTP for verification



Now your test case is ready. 


Observe the Email Inbox and visually verify that the email has been received. 




Why Do We Need Email Testing?



Each component in the system (Web/Mobile applications) may have different purposes to send Emails. Integration between components and Email plays a vital role in reaching end-user with proper notifications. 

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.


Common Real-time Scenarios and Validation points for Emails

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 the 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 the respective application’s page with the 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 log in to the application, 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 the 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 get 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 the password successfully within a specified duration
    • Try to click on the link after the duration has passed – The 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 an 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 an 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, feedback, etc.


4) 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 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


5) 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:

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

  • A link in the email should take a user to the order’s details page in the application UI. There should be an exact match between information in Email and application UI



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 the 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 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 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