In a previous Newsletter, we explained the two types of form validation that websites implement, one that happens upon submitting the information to the server, called server-side validation and the other executed locally, called client-side validation.

Let’s analyse the following email field validation execution on the Newsletter Sign Up form on weather.com

This form is an excellent example of client-side validation implementation that shows a warning message upon leaving the field.

This execution was submitted as a bug:

Notice that the user enters two different email addresses:

Both inputs are using not standard characters, and the form accepts them as valid, which is what the expected result of this bug report is that the form shouldn’t accept an invalid email address.

Nevertheless, both are valid email addresses, so the form accepts them.

What makes an input valid? A validation system checks against a specific rule or set of rules (e.g. passwords) whether the user’s information meets it. If the input is somehow incorrect, a message warns users and prevents them from progressing.

An email address is valid if it meets the format: local part + @ + domain, which both email addresses in this example meet.

What generates this idea of an invalid email address? The assumption that a non-existent email address is invalid (e.g. a made-up or not yet open). However, what makes an email address invalid is if its syntax is correct, in other words, if it follows this format.

Some tools can tell you whether the syntax of an email address is valid or not that could help you while testing, one of which is verifalia.

Here is the result of this tool after analysing the syntax of the email addresses of this example:

To master this particular input validation subject, you only need to head to our comprehensive Academy article: ❝Testing Email Validation❞.

Another weather.com example of a common testing mistake is translating the website.

The following example of a submitted content bug shows that some English text is shown on the German version of the website, which is indeed a content bug if the website, under the scope of the test cycle, states that other languages can be tested.

When the language of a website is changed, the content changes and, therefore, its version, which translates into testing a completely different environment.

In this case, the website under scope is the English version, not the German version, which is why such a bug shouldn’t have been submitted.

However, when we’re testing and we are ❝in the zone❞, we might unintentionally leave the environment and keep testing.

If this is the case, there is a simple trick you can start implementing to avoid such a mistake, and this is constantly comparing the URL of the environment given on the OVERVIEW page of the test with the one you’ve found the bug.

If any of the domains or the path of the URL of the bug differs from the given one, then it’s most likely that you’ve left the environment in scope, so it’s better to get back to the correct environment immediately.

Remember the structure of a URL to compare the URLs during your testing sessions to avoid unnecessary rejection.