Email contact form test cases
When conducting research for this article, the first type of email test cases I learned about were the ones used for email contact forms.
And yes, while I know it might not sound like the most exciting thing to do, email contact form testing can be what prevents you from losing leads, customer feedback, support queries, and so on.
The QA team I shadowed for this task did a very thorough job of ensuring the email contact form they were testing was not only functional but also secure, reliable, and user-friendly.
Here is the list of test cases that were written and conducted:
Form fields:
- Checked if all required fields (name field, email address field/email ID field, message field, etc.) are validated for input.
- Tested for validation messages/notifications when required fields are left blank.
- Validated format-specific fields (e.g., email address, which needs to follow the correct format but can include special characters like dashes or underscores).
Email address:
- Ensured the form detects invalid email address formats (e.g., email addresses containing an unusual top-level domain, square brackets but no IP address, more than two dots in case of a subdomain, a trailing dot or leading dot, local part over 64 characters, and so on).
- Tested with invalid and valid email addresses to see if the form behaves as expected.
Input length:
- Checked the maximum and minimum character limits for fields like name and message.
- Validated the behavior when the input exceeded the character limit.
Submit button:
- Verified the submit button works correctly after filling out the form.
- Tested the behavior of the form when the submit button is clicked with incomplete/invalid data.
Confirmation message:
- Checked if a confirmation email is sent to the user after successful submission.
- Verified the content and format of the confirmation message.
Error handling:
- Tested how the form handles network issues or server errors.
- Ensured appropriate error messages are displayed for different types of errors.
Cross-browser compatibility:
- Tested the form on different browsers to ensure consistent functionality and appearance.
Responsiveness for various devices:
- Ensured the form was easily usable on mobile devices with different screen sizes.
Security:
- Tested for vulnerabilities like SQL injection, XSS (Cross-Site Scripting), and CSRF (Cross-Site Request Forgery).
- Ensured that captcha or similar mechanisms were in place.
Integration:
- Checked if the form correctly integrates with backend systems like databases or email servers.
User interface and accessibility:
- Verified the form is user-friendly and accessible, including clear labels, readable fonts, and a logical layout.
- Ensured accessibility for users with disabilities, like keyboard navigation and screen reader compatibility.
Contact forms can be built in a range of programming languages. Check out our tutorials on some of the most popular ones:
Email body/content test cases
After email contact forms, the time came to test the body and content of emails. These types of test cases are quite important for a range of reasons, including:
- They ensure that the email correctly addresses the intended context and user actions, especially in the case of dynamic content and personalized messages.
- They ensure that the various formatting elements are rendered correctly, regardless of email client or device.
- They verify that the links and CTAs within the email are functional and lead to the correct destinations.
- They assess how emails behave in case of errors or unexpected user actions.
- They ensure that email loading time is not hindered by media elements.
- They confirm that the language translations, from English to other languages, for example, and any cultural content are accurate and appropriate.
To learn about email body/content test cases, I shadowed the same QA team joined by a few email marketers who were in charge of giving the team pointers on coming up with test case ideas.
The test cases completed can be put into three different categories:
Web browser email rendering
The idea behind our email rendering test cases was to focus on several aspects of the email body/content and ensure the email in its entirety displays correctly and consistently on different browsers.
Completing these test cases is critical as each browser has its own way of interpreting and rendering HTML and CSS, which might lead to an inconsistent way of displaying the layout, formatting, and interactive elements. An email marketer’s nightmare!
These were our web browser email rendering test cases:
Layout and structure:
- Checked if the email layout (headers, footers, columns) was consistent across browsers.
- Ensured that the spacing, alignment, and positioning of elements were as intended.
Fonts and text styling:
- Confirmed that the chosen fonts are displayed correctly.
- Checked text size, color, and styling (bold, italics) across different browsers.
Links and buttons:
- Tested all hyperlinks and buttons to ensure they were clickable and redirected to the correct URL.
- Verified the visual and functional aspects of buttons, such as hover effects.
Interactive elements:
- Tested interactive elements (like dropdowns and tabs) functionality.
Color rendering:
- Checked how colors are rendered in different browsers to ensure consistency and visibility.
Accessibility features:
- Tested for accessibility features like alt text for images and ensured they were functional.
Loading speed:
- Assessed the loading time of the email.
Special characters and emojis:
- Checked if special characters and emojis are displayed correctly.
Fallbacks for unsupported features:
- Tested fallbacks for features that are not supported by certain browsers or email clients (like web fonts).
Incognito/private mode:
- Verified rendering in private or incognito modes.
Responsiveness
After web browser rendering test cases, we took the next logical step and proceeded to write and conduct email responsiveness test cases.
Through these test cases, we can verify whether an email’s design is of an adaptive and responsive nature. And if yes, we can also guarantee that no matter what device a user is on, the email content will be legible, accessible, and consistent.
Our test case batch included the following:
Layout adaptability:
- Verified that the email layout was adjusted to fit the screen sizes of different devices, such as desktops, tablets, and smartphones.
- Checked if multi-column layouts collapsed or stacked appropriately on smaller screens.
Readable text:
- Ensured that text remained legible without zooming on all devices, including checking font sizes, line spacing, and paragraph formatting.
Scalable images:
- Ensured that images scaled correctly to fit various screen sizes, were clearly visible, and were not cut off or excessively large on smaller screens.
Clickable elements:
- Verified that links and buttons were easily clickable on touch devices, adequately spaced, and large enough to tap without zooming.
Content visibility:
- Ensured all critical information and calls-to-action were prominently visible without horizontal scrolling or zooming.
Email header and footer:
- Checked that the header and footer content scaled well and was easily readable across devices.
Media queries:
- Ensured that media queries worked correctly to apply different CSS styles for different screen sizes.
Load time:
- Assessed the loading times on mobile devices.
Orientation responsiveness:
- Tested both landscape and portrait orientations on mobile devices to ensure the layout was adjusted correctly.
Accessibility:
- Ensured that the email was accessible in terms of contrast, font sizes, and alt text for images, especially on smaller screens.
Preview text:
- Checked how the preview text displayed across various devices.
HTML template code validity
As HTML template code validity test cases are quite, to no surprise, HTML code focused, the QA team and I employed the help of a web developer to write and conduct them.
With the tests, our aim was to ensure the code used in emails was error-free and adhered to web standards.
These were the test cases we came up with:
HTML and CSS standards compliance:
- Checked if the HTML and CSS code adhered to specific standards.
Compatibility with email clients:
- Ensured that the HTML and CSS used were compatible with a wide range of email clients (like Gmail, Outlook, and Apple Mail) and web browsers.
Inline CSS:
- Tested whether CSS was correctly inlined and no external or internal stylesheets were used.
Use of tables for layout:
- Ensured that the layout used tables where necessary for better compatibility with email clients.
Fallbacks for unsupported features:
- Checked fallbacks for HTML or CSS features that were not supported in certain email clients.
Email sending test cases
Email contact form test cases? Check! Email body/content test cases? Check! So, what test case type was left for us to do? You guessed it, email sending!
With email sending test cases, your goal should be to ensure that an email delivery system is reliable and efficient by focusing on its functionality and performance. In other words, email sending test cases should verify that emails are sent correctly and suffer no delays or failures regardless of whether they’re bulk or single emails, plain text or HTML emails, emails with or without attachments, and so on.
If you go really “in-depth” with your email sending test cases, they can also help confirm if your email sending adheres to technical standards and protocols, as well as how your system handles errors and maintains speed and accuracy when it encounters high volumes of emails.
Here are the email test cases we conducted:
Email deliverability:
- Checked if emails successfully reached recipients’ inboxes, not spam folders.
- Verified email content, layout, and links for issues affecting deliverability.
Sender reputation:
- Evaluated the trustworthiness of the email domain name and IP address.
- Monitored for inclusion in blacklists.
Learn the ins and outs of email deliverability and sender reputation through dedicated Mailtrap tutorials:
- Better Email Deliverability 2024: What affects it?
- Email Deliverability VS Email Delivery in 3 Minutes
- Email Deliverability Monitoring: Do You Need Deliverability Experts’ Help?
- Email Sender Reputation Made Simple
Authentication:
- Verified correct implementation of SPF, DKIM, and DMARC protocols.
- Ensured emails are not flagged as spoofed or fraudulent by recipient servers.
Spam score:
- Analyzed emails for factors triggering spam filters (keywords, formatting, links).
- Utilized spam score testing tools to identify and rectify problematic elements.
Regulatory compliance:
- Ensured compliance with legal standards like GDPR, CAN-SPAM Act, or CASL.
- Reviewed email content, headers, and data handling practices for legal adherence.
Email list quality:
- Evaluated the accuracy and relevance of email addresses in an email list.
- Identified and removed invalid, inactive, or duplicate addresses.
How to write email test cases
Test case after test case, it seems that we’ve covered it all! And although it required time and effort, I’d say the team and I handled the test case writing and execution with ease thanks to having our own effective guide on the matter.
We’ll now take you through the steps included in our guide using our test case example!
- Defining the objective
Every test case needs a clear purpose/objective. An objective that is well-defined, can set the stage for developing scenarios and criteria, guide the testing procedures, enable systematic and effective testing, as well as allow for precise measurements of performance.
