Visual and Content Upgrading to Low Functional Bugs?
There are specific scenarios where a content or visual categorisation of a bug is not the better way to describe the issue and stand out its importance for customers, users and testers.
Yes, testers! Upgrading visual or content bugs to functional ones means more money for you, so this is a win–win for all parties involved.
So, what does the Academy say about this? In the article ❝Bug Types (Summary)❞ you can read:
❝As soon as a content or a visual bug prevents a functionality, it should be reported as a functional bug, even though it is not actually the function itself that is defective. An important case for when a content bug should be submitted as a functional bug is when it occurs in a functional component of the product – namely linking problems in the navigation menu, header, footer, or a breadcrumb navigation. Such problems are typically Low functional bugs.❞
Let's consider the following scenario:
Click on the hamburger button
Click on the COVID–19 Dashboard link
This bug was submitted as a content bug, which makes sense since our Academy article ❝Content Bugs❞ states that ❝Defective redirections in general❞ are considered content bugs; however, there is an important exception: ❝(...) linking problems in the navigation menu, header, footer, or a breadcrumb navigation. Such problems are typically Low bugs.❞
Therefore, this bug report and similar scenarios must be submitted as low-functional bugs.
If identifying the correct feature where an element (link, button...) belongs, remember that you can always consult ❝The Standard Features Descriptions❞ article, which you can find the definition with examples of the most common environment features implemented on digital products.
Let's take a look at another example!
This time the bug was correctly submitted as a LOW functional bug (great job, mail.cruzmasloe!) with a visual root cause.
Click or tap to navigate to the Academy article.
Notice that the ❝Default billing address updated❞ flash message is too close to the checkbox ❝Set as default billing address❞ which indicates that the size of this message is larger than the green one we can see, overlapping the checkbox and preventing users from accessing the functionality.
This temporary blocking always needs to be identified before deciding the correct type of bug. As per Academy: ❝If the functionality can be reached intuitively and easily via a different path or option, users are de facto not prevented from using the functionality, so the problem may not be submitted as a functional bug. It remains a visual problem.❞
This may seem tricky now that you're in the Greenhorn phase; however, the more test cycles you join, the more experience you gain and deciding whether content or visual bugs are functional issues will become second nature to you.
How to handle TLs' Requests?
Information requests, what's that? Sometimes additional information is needed to identify a bug, like screen size or the device model used; in such cases, customers and team leaders could send an information request.
However, numerous bug reports get rejected because, after 24 hours, they were never seen or were unattended, causing an easily avoidable rejection reason!
This is the meaning of this message:
Tap on the image to know more!
In a nutshell: ❝An Information request represents a request aimed to clarify or enhance your bug report. It can be sent by TL or customer. When you get an Information Request from the TL, it means that TL thinks that your bug report has the potential to be forwarded to the customer. Consider this as an opportunity to improve. Read the Information Request and act according to your TL's request. Upon submitting the required information wait patiently while your TL reviews the bug report once again. Don't send a message in the Chat, and don't add additional comments. TL will get a notification that you responded to the request and will review the submission as soon as possible.❞.
What do you do when you get an information request? Easy peasy!
Refrain from getting rejected your bug reports for simple reasons like not attending to a request since rejections affect your quality score, which negatively impacts the test invitations you get.