Online, there are software applications that collect your email ID.
These software applications can be all types of testers, like eCommerce websites, scheduling an appointment, or buying tickets to a concert.
You should include email testing as a part of your email marketing game plan.
When you will create an email address field validation test scenarios apply to all testers and avoid invalid emails.
If you don't know how to write test cases for email, this is exactly what you will learn with us.
In this article, we tackle how to write email validation test cases.
I) What are the Acceptance Criteria for email address validation test cases?
Acceptance criteria is a condition that validates whether the software application is working as intended with respect to the end-user.
Acceptance criteria are there to help you judge the intent of the applications' end-user rather than the steps.
These are the steps to go through for the email address validation test cases:
- Single email verification and Bulk email verification
- Syntax validation
- DNS Lookup (domain server verification)
- Check for unnecessary emails
- Inbox verify or mailbox check
After all these steps, if everything goes well, you will validate the email address.
This means that your email addresses are correct.
You can definitely run an email marketing campaign.
And if it shows invalid or risky then they have some kind of DNS or other problem, remove them from your email list.
II) Why do we need Email Testing?
Your recipients receive emails from applications like Gmail, Yahoo, Outlook, and each of these clients will render your emails differently.
These variations can affect how your emails will be received.
If you’re not email testing effectively you might be losing market and business.
Email testing makes you able to analyze the results directly from your audience.
Your audience is telling you what they like and doesn't like about your emails, and you are able to adjust your email campaigns accordingly.
Activation Emails
At the point when a client registers to applications interestingly, he/she really wants to enact the record by tapping on the initiation connection sent in Email.
This likewise confirms the client's given Email address is substantial and open.
Approval focuses are as beneath:
Initiation Link or button
- Tapping on it should:Take the client to separate application's page with client account signed in
Client's Email record ought to get confirmed consequently assuming that the application page is arrived at effectively through Email
Term
- Check for the term inside which the connection must be clicked and confirmed.
Confirm inside the predefined span.
Attempt to confirm after the length has passed
- Record ought not be actuated and Email ought to stay unconfirmed.
Forgot Password Emails
At the point when a client fails to remember the secret word to login to the application, a failed to remember secret key stream can be performed to get an Email with connection to reset the secret key (highlight shifts from one application to another. This is the overall one).
Approval focuses are as underneath:
Reset secret word interface: Clicking on it ought to take the client to separate application's page to reset the secret phrase
A few applications will ask clients to respond to security inquiries prior to showing the reset secret word page, and some will have security questions coordinated with the reset secret key page itself.
Some won't have this component at allIf client resets the secret word effectively, the connection in the Forgot Password Email that has been gotten ought to get deactivated and non-functionalIf client drops the reset secret phrase stream.
The connection in the Forgot Password Email that has been gotten ought to stay enacted
Check for the term inside which the connection must be clicked for secret key reset.
Click on the connection and reset the secret word effectively inside indicated duration.
Try to tap on the connection after the span has passed.
Due Date Notifications
This is to remind the client about the move to make in a specific number of days.
This generally is the bill installments, making a move on forthcoming things (model: tolerating or dismissing the welcome to some occasion in a specific number of days, submitting structures, etc..).
Approval focuses are as underneath:
Number of Due days/Due dateIf email informs about various due days then the number ought to be either at least zero, zero days intended to be the ongoing date the due is. It ought not be in bad numbers.
In the event that an application email tells about a Due date (Calendar date) the date ought to be either the ongoing one or what's in store.
Check is the kind of activity's expectations. It ought to plainly state what sort of move that client needs to initiate.
Be it the bill installment, entries, criticisms, and so on.
Overdue Notifications
This is to illuminate the client about the due date has passed.
This normally is to illuminate the client that he/she has not made a move on the things inside due date.
Number of Overdue days
Make sure that the quantity of past due days ought to be possibly at least one. It ought to never be zero or negative numbers
FrequencyFew applications will have the arrangement to modify late messages to be sent day to day/week by week/month to month, when the due date has passed, until the client finishes the activity.
Scarcely any applications will have the standard notice to be sent just once solely after the due date has passed.
Subscriptions
This changes according to client necessities.
The client can choose one among the accompanying Daily, Weekly, Bi-Monthly or Monthly memberships.
This will generally be for pamphlets, refreshes, offers, and so on.
FrequencyEmails ought to be sent according to client determination for a membership.
On the off chance that Daily membership email ought to be sent only once in a day.
On the off chance that week after week, once in seven days. Furthermore, goes on…
LinksAny joins in the email ought to explore the application's separate page.
On the off chance that the email is for refreshes, the connection ought to divert to the page where updates are intended to be shown.
On the off chance that the email is for offers, the connection ought to divert to the Offers page of the application.
It relies upon the kind of membership the client has chosen.
Forms
Emails plans client to give feedback through forms/link to forms.
Approval focuses are as beneath:
Link in the email ought to divert the user to the form submission page of the application according to the kind of structure the user is expected to submit
Once submitted, tapping on the link again ought to advise the user that the form has previously been submitted.
It shouldn't permit the user to re-submit the form.
Confirmation Emails
Emails notify the client about the affirmation of the movie made.
This typically is the booking affirmations, request affirmations, inquiry affirmations, and so on..
Approval focuses are as beneath:
Affirmation subtleties:
The request number/booking number ought to be right and match the number shown in the application UI code.
As it is the identifier to follow the orders/appointments, it ought to be extraordinary (to be approved in backend - DB) all through the application.
No orders/appointments ought to have a similar identifier.
Alongside the number, it ought to likewise be approved for the sort of request, client data, charging address, delivering address, and cost.
All the data ought to be precisely like what the client has given in the application UI.
Joins: A connection in the email ought to take a client to the request's subtleties page in the application UI.
There ought to be a precise match between data in Email and application UI.
Chat Transcript
A client gets the whole chat transcript as Email.
This typically happens once the Live Chat with Customer support is finished.
Check the client's name who asked for online support.
Check that the chat is available in the email with the sender's details for each chat entry (Person name, Date and time the talk message was sent, etc.,).
Emails with attachment
The client receives Emails with attachments.
attachments can be shielded/unprotected passwords.
A significant part of the time, The client domain gets Emails with connections.
Connections can be secured/unprotected passwords.
Generally speaking, connections can be the articulations from monetary spaces, End User License Agreement for reference, Terms and Conditions for reference, and so on.
On the other hand, this differs from one application to another.
Sort of the attachments:
Legitimate document types ought to be sent as a attachments
You ought to filter every one of the opened attachments prior to downloading/opening.
You can redo this at the attachments level at the backend, similar to, infection output to be performed just while downloading, just while opening, for both downloading and opening.
Secret word safeguarded attachments ought to download without requesting the secret key.
In any case, while opening it either from Email itself or opening the downloaded duplicate ought to continuously request the secret phrase.
Mistaken secret word sections here will be endless as the neighborhood duplicate can't be followed online to lock the attachments can be the explanations from financial spaces, End User License Agreement for reference, Terms and Conditions for reference, etc.
Obviously, this changes starting with one application then onto the next.
Endorsement centers are as underneath:
Sort of the attachments
Significant record types should be sent as an association.
All of the associations being opened should be contamination really looked at preceding downloading/opening.
This again can be altered at application level at the backend, like, disease result to be performed just while downloading, just while opening, for both downloading and opening.
Secret word protected The client gets Emails with connections.
Connections can be secured/unprotected passwords.
By and large, connections can be the explanations from monetary areas, End User License Agreement for reference, Terms and Conditions for reference, and so on.
Of course, this shifts from one application to another.
Approval focuses are as beneath:
Kind of the connection
Substantial document types ought to be sent as a connection.
Every one of the connections domains being opened ought to be infection checked prior to downloading/opening.
This again can be tweaked at application level at the backend, similar to, infection output to be performed just while downloading, just while opening, for both downloading and opening.
Secret phrase safeguarded connections ought to download without requesting the secret key.
In any case, while opening it either from Email itself or opening the downloaded duplicate ought to continuously request the secret word.
Wrong secret word passages here will be endless as the neighborhood duplicate can't be followed online to lock the attachment ought to download without mentioning the mystery expression.
However, while opening it either from Email itself or opening the downloaded copy should constantly demand the mystery word.
Incorrect mystery word sections here will be unending as the close by copy can't be followed online to lock the association
III) What are the Test Cases for Email Address Validation?
Negative Scenarios
Here are some examples of negative scenarios:
- Verify an email id cannot exceed 254 characters.
- Verify the missing @ symbol in the email id field.
- Verify the missing domain in the email id field.
- Verify gibberish or garbage is not accepted in the email id text box.
- Verify the missing username in the email id field.
- Verify the encoded HTMLwithin the email id field is invalid.
- Verify the leading dot in the email id text box is invalid.
- Verifytrailing dot in the email id textbox is invalid.
- Verify multiple dots in the email field.
- Verify Unicode char in the address in the email text box.
- Verifyinvalid IP address format in the email text box.
- Verifying multiple dots in the domain is invalid.
- Verify invalid email addresses that look like: plaintextaddress@#@@##@%^%#$@#$@#.com@email.comJohn Doe <example@email.com>example.email.comexample@example@email.com.example@email.comexample.@email.comexample…example@email.comおえあいう@example.comexample@email.com (John Doe)example@emailexample@-email.comexample@email.webexample@111.222.333.44444example@email…comCAT…123@email.com”(),:;<>[\]@email.comobviously”not”correct@email.comexample\ is”especially”not\allowed@email.com
Testing Diminishing Returns
There are diminishing returns to testing. That's why developers should use a thoroughly tested library or regex for this functionality.
Follow this list of some tests you might be tempted to run, but you don't need to:
- Verify too many symbols (@).
- Verify all top-level domains.
- Verify non-existent top-level domains.
As a tester, you should better discuss with the developer about the library code's rights and wrongs.
Also, review your developer's code on their best laptop for Android Development for the story you are working on.
This tip will help you target your testing efforts during email addresses testing.
IV) Writing Sample Test Scenarios
Here are tips for writing effective test cases.
- Write, To The Point Descriptions: keep the description simple and informative.
- Actively Use A Test Case Management Tool.
- Monitor All The Test Cases.
- Aim For 100% Test Coverage.
- Beware of Dependent Test Cases - You may have a test case X which will only be executed after performing test case Y and test case Z, sequentially. This scenario happens when two modules are non-mutually exclusive. Draft a scenario after figuring out the dependent test cases to not create bugs.
- Make use of automation testing - write ‘clean code’ to provide better maintainability and readability.
- Be Intent Specific: Acceptance criteria are imperative to writing effective test cases.
- Prioritize Your Test Cases Well.
- Stay In Your Lane - Don't let an assumption of features and functionalities deviate you from actual requirements that were originally required by the client.
- Therefore, it is always better to develop a thorough understanding of the SRS (Software Requirement Specification) document.
V) Conclusion for Email Address Field Validation Test Cases
Testing Emails is as important as most of the application's integrated components are integrated with this functionality.
For each type of email, you should have separate test cases to cover all the aspects to test.
keep in mind that all types of email test cases should have:
- Regression testing
- Adhoc testing
- Localization testing
- UAT testing
- Production testing
This way, you will be more able to create error-free email address field validation tests cases.
