In most web and mobile applications, Email authentication is considered one of the most important parts of testing, to ensure quality in the Email component as well as with other components of the system. .
The emails activated in different situations are considered to be authenticated by testing all its components including an Email template, Links / buttons in Email, From, To, Cc, Bcc, Files Attachment, Content as Email notification, etc.
Why Do We Need to Check Email?
Each component in the system (Web / Mobile application) may have different purposes for sending Email. Integration between component (s) and Email plays an important role in reaching end users with appropriate notifications. Any negligence when we confirm this feature will lead to misunderstandings for customers, hacking, etc.
For example, imagine a situation where a user has received an email to reset their password. What happens if the button / link Reset password or the URL provided to copy paste in the browser does not work? The only option left here is to contact customer support, imagine a situation where users constantly receive daily emails about the due date to pay bills 10-15 days in advance or Receive a reminder after due date. Extremely uncomfortable right?
There are many situations in which email has become an integral part of our lives because they mean keeping users up to date with accurate information.
Real-time situations and points requiring authentication
The confirmation point in the Email test varies from one type to another and can be from one application to another. Normally, all emails must be validated according to the form (including application logo, application name, user address, Content – Copyright, Customer support details), date and time stamp for the different time-zone.
Here we will discuss some common email types that most people know (all the verification points provided below are basic tests that testers must take while checking email. application).
1. Email activation
When a user registers the application for the first time, he / she needs to activate his account by clicking on the activation link sent in the Email. This also verifies that the user’s given Email address is valid and accessible.
The verification point is as follows:
- Activation link or button – Clicking it will:
- Bringing users to the page of the application corresponding to the logged in user account
- The user’s Email account will be verified automatically if the application page is successfully accessed via Email
- Duration – Check how long the link must be clicked and verified.
- Verify within the prescribed time limit
- Attempt to verify after timeout – Account is not activated and Email will not be verified
2. Forget email
When a user forgets a password to log in to an application, a forgotten password flow can be sent to receive an email with a link to reset the password (features vary by application.
The verification point is as follows:
- Reset password link:
- Clicking on it will take the user to the page of the corresponding application to reset the password
- Some applications will ask users to answer security questions before displaying a reset password page, and some applications will have a security question integrated with the password reset page and some will not. has this feature.
- If the user successfully resets the password, the link in the Email Forgot the password received will be disabled and inactive.
- If the user cancels the password reset stream, the link in the Forgot Email Received Link will remain enabled
- Duration – Check how long the link must be clicked to reset the password
- Click the link and reset your password successfully within the specified time period
- Try clicking the link after the time has elapsed – The link will be deactivated and expires
3. Notice the due date
This is to remind users of actions taken on a specific number of days. This is usually to pay the bill, take action on items that are pending (for example, accept or decline invitations to attend to certain events on specific dates, submit forms, etc.). ).
The verification point is as follows:
- Number of due dates / Due dates
- If the email notifies you of an expiration date, it must be zero or more, the date does not mean the current date is due. It should not be negative. If the email notifies you that the due date (calendar day) is the current or future date.
- Type of action
- Check what kind of action is needed. Should specify the type of action that the user must perform. May be bill payment, submission, feedback, etc.
4. Notice overdue
This is to notify the user of the past due date. This is usually to notify users that they have not taken action on items on the due date.
- Number of days overdue
- Check if the number of overdue days is one or more. Should never be zero or negative
- Frequency
- Very few applications will have permissions to customize overdue emails sent daily / weekly / monthly, after expiry until the user completes the action. Very few applications will have standard notifications sent only once after the expiry.
5. Sign up
This varies according to user requirements. Users can select one of the following Daily, Weekly, Two-Month or Monthly subscriptions. This will usually be for newsletters, updates, offers, etc.
- Frequency
- Email should be sent according to the user’s selection to a subscription. If daily, the registration email should be sent once in a day. If weekly, that means once in a week.
- Link
- Every link in the email will navigate to the corresponding page of the application. If the email is for an update, then the link will redirect to the page where the update is displayed. If the email is for the offer, then the link will redirect to the app’s Deals page. It depends on the type of registered user selected.
6. Form
The email here intends to the user to provide feedback via the form / link to the form. The verification point is as follows:
- Link
- The link in the email will redirect the user to the application’s form submission page according to the type of user required to submit
- Once submitted, clicking the link again will notify the user that the form has been submitted. It should not allow users to resubmit the form
7. Email confirmation
The email is here to inform the user about the confirmation of the action taken. These are usually booking confirmations, order confirmations, query confirmations, etc.
The verification point is as follows:
- Confirmation details:
- The order number / reservation number must be accurate and match the number shown in the application user interface. Because it is an identifier for tracking orders / reservations, it is unique (authenticated in the backen – DB) throughout the application. No orders / reservations should share the same identifier.
- Along with that, it also needs to be confirmed for the order type, user information, billing address, shipping address and price. All information must be identical to what the user provided in the application user interface.
- Link:
- A link in the email will take the user to the order details page in the application user interface. An exact match is required between the information in the Email and the application user interface
8. Transcript of conversation
Here, one user receives the entire copy of the chat as an Email. This is usually once the Live Chat with customer support ends.
Confirmation point as below
- Detail
- Check the name of the online support provider. Check if the entire conversation is in the email with details of the sender for each chat item (Name of person, Date and time the chat message was sent, etc.)
9. Email has attachments
Users receive Email with attachments. Attachments may be password protected / unprotected. These are usually reports from the financial field, End User License Agreement for reference, Terms & Conditions for reference, etc., this again varies from application to application.
The verification point is as follows:
- Attachment type
- Valid file types should be sent as attachments. All attachments that are currently open must be scanned for viruses before downloading / opening. This can once again be customized at the application level in the backend, as the virus scan is only done when downloading, only when open, for both download and open.
- The attached password should download without asking for a password. But while opening it from Email or opening the downloaded copy, you must always ask for the password. Incorrect password entries here will not be determined because local copies cannot be tracked online to lock attachments.
Types of emails
The type of email can be HTML (colorful and attractive to users, users interested to read Full Email) or Plain Text (just a text).
HTML is the most preferred and is often set as the default in most backend applications. If required, applications can choose to send plain text email to the user, again this requires a change in the backend.
Activation email:
Email can be sent immediately or as a summary / batch. The email is immediately triggered by user action. These are usually activation emails, reset password emails, chat copy, confirmation emails, etc., i.e. the Summary / batch emails are activated based on the settings in the backend section of the application.
The email activation point will be determined to activate at a specific time (for example, the 3rd day of the week at 12:00 AM). These will usually be reports from the financial sector (bank statements), due dates for invoices, overdue notices, subscriptions, etc.
Bouncebacks:
This is a very common case when emails are bounced back when they are sent to an invalid email address. Typically, email addresses are disabled / no longer used and absolutely nonexistent – are bounce candidates.
The server usually tries several times to send an email to the intended address. When it fails to reach the intended email address, it will be bounced back and will create an entry in the server for its failure. There will be another server to maintain these types of activities and is often referred to as bounce server. There can be several reasons for an email to fail by reaching its users.
Here are a few other points for failure:
- Email server has been down for a long time
- The algorithm to find a short route to reach the user does not work correctly and takes a lot of time to reach the user, by which time it may have passed the time specified to reach the user. This is often referred to as increasing the number of hops
- The user’s email domain name has been inactive for a long time
- The user account for the application is not enabled to receive email
Localized scope for checking emails
When the application supports multiple languages, the support will also expand to Email.
All Emails sent must be in the user profile language. If the user has English as the profile language, all emails sent to him / her must be in English. If the user’s profile language is French, then all emails sent to him / her must be in French. The user profile language may be one-time installation or may be changed as needed, depending on the application’s settings.
Email must be sent in the language that the user has at the time it is activated.
Common verification points for checking localization of emails are as follows:
- Headline
- Email content
- Content – body text
- Link name / button name
- Copyright information
- Customer support details
Standard / Customize email
- Email can be customized at the backend
For example, some applications support users to customize Email when they are sent. Users may change here the subject line and / or email content for convenience or for easy identification. In this case, thorough testing must be done by the testing team because the chances of penetration are very high.
The checks must be made to – send HTML, Java, SQL, etc. All of this will fail to increase the level of security. If the application does not support customizing emails, all emails sent will follow the standard subject / content as set by an application.
Conclusion
Email checking is an important activity because most application components are integrated with this function.
Full support and effort is required to fully test the email functionality of the application. This needs to be planned a lot before starting the actual test and must go hand in hand with testing each component / component concerned.
Check email must have separate test cases written for each type of email including all aspects to check. This should be done in all types of regression testing, adhoc testing, localization testing, UAT testing and production testing.
Anything wrong in Email in real time, will leave a bad impression on the application, the customer and eventually, it will forward to those who test the application. Therefore, Email Authentication is a very important and required activity in Software testing.