At Test IO, highlighting bugs in screenshots is mandatory for documenting bugs.

These are our screenshot-specific rules:

We also have an excellent example of how to report a visual bug in our article, ❝Common mistakes in Attachments❞.

However, sometimes identifying what should be highlighted gets tricky since it might only look straightforward sometimes, so here is an example of what never to do and how to highlight bugs in screenshots.

Never use hand drawing when highlighting bugs, it looks unprofessional, and sometimes the bugs get unintentionally covered by the highlighting.

Also, avoid highlighting entire sections or elements:

Highlight only the elements compromised, and use red for better contrast:

A wrong version of this screenshot would highlight all months, the year and the ❝View❞ button since it won't directly tell which elements are trimmed off.

REMINDER: The purpose of highlighting a bug in a screenshot is to make people instantly see it without spending time finding it or trying to understand it.

Forms are a prime example of inconsistencies that can be classified as legitimate bugs, as they reveal how the functionality was originally intended.

It’s important to remember that HTML forms gather user inputs such as checkboxes, radio, and submit buttons. In this context, we are examining ❝The HTML <input> element (that) is the most used form element.❞

Forms usually need some validation. When on a website, the same form is found on different pages and only sometimes is validated; this could be because the validation is conflicting on the page where it is not triggering or implemented yet. No matter why this happens, an educated guess tells us that it must always validate users’ input and that such a system should be implemented.

Let’s consider the form JOIN on ASOS as an example. One of the requirements under DATE OF BIRTH is to be at least 16 years old to use ASOS. If the user’s input is below this age, a validation message will appear saying, ❝Oops. Looks like you’re too young to use ASOS.❞

Interestingly, the system successfully confirms changes with an incorrect input made through the MY DETAILS input form within a user’s account.

Generally, bug inconsistencies are categorised as low severity bugs because technically they're not bugs since, in this case, the validation of the user's age hasn't been implemented yet, so it cannot lead to glitches; however, implementation is already on the environment, indicating an intention of how the functionality is intended to work and if there is an issue within on other pages or sections of the environment, the problem could escalate.

TIP: When testing forms is crucial to show that there is some implemented validation when users enter any character that makes sense to enter; trying to input numbers for name or symbols for date information is not typical user behaviour and is considered edge cases: ❝Edge case bugs that are relevant for our customers are forwarded as Low bugs. Irrelevant cases, which account for most edge case bugs, will be rejected.❞

Forced bugs result from behaviours that won’t occur under normal circumstances; since at Test IO, we test websites as closely as users would use them, these bugs are out of scope.

❝Forcing a bug by nontypical behavior or special conditions is generally out of scope as such bugs are not relevant for our customers.❞

These are examples of forced bug scenarios:

There is another scenario where the user attempts to bypass the necessary conditions for a specific functionality to operate as intended. This can be seen in the following example:

It appears that the user is being redirected to a 404 page after clicking the ADD TO CART button, which could be mistaken for a real bug.

However, notice that the missing page also tells what the issue is: the user didn't select the size of the item.

It is not common for users to add an item to their cart without selecting the appropriate size. After all, no one would want to pay for something that would not fit them properly.

On the other hand, when a system provides information about an issue and how to resolve it, it cannot be classified as a bug. This behaviour is anticipated as it is intended to assist users in determining the problem.

In this screencast, under the big ❝OOPS!❞, users can also read: ❝You need to choose options for your item❞.

PRO TIP: Always use websites how a person would use them. Users always want to get want they want, not prevent themselves from finding it. Suppose you find yourself creating ways to avoid accomplishing a user’s primary purpose on an environment (a.k.a. trying to break the environment). In that case, think twice since this kind of testing only leads to wasting time and rejections.