A bug is a software-related problem. If something on a website or an application does not work as intended, this “error” is a bug. Here at test IO, we distinguish between the following bug types:
Functional Bugs
Functional bugs are related to the functionality of a piece of software, e.g. a button doesn’t submit a form, the search doesn’t react to the user input, an app crashes, etc. It might be a functional issue whenever you perform an action and the website/app doesn’t respond as expected.
How to determine if app behavior is a functional bug:
Try to figure out if a feature is designed a particular way or if it is actually broken. Test it by itself and in combination with other features to spot potential differences.
Think about what the customer’s intentions might have been and consider that the product might just work the way it was implemented.
Find evidence that something is not working as it should and support your claim.
Example: A webshop functionality works differently than in other webshops you know. It doesn’t mean that the functionality is broken. Customers can implement their products however they want.
Example: If you claim that a form field is not validated and that it’s a bug, please make sure there is any indication that the field is intended to be validated. You can provide this evidence by showing that the field is validated in some cases but not others. If you don’t provide any evidence, it’s an unproven claim.
A visual or content problem becomes a functional problem when it hinders a functionality and thus should be reported as a functional bug.
If a piece of functionality consistently works the same way in different scenarios and without obvious problems, it’s probably intended (not a bug).
Severity Assessment
What severity level is appropriate for a functional bug depends on several factors: the problem's functional impact, the extent of the problem, do workarounds exist or if it is a showstopper, whether there are potential and notable losses of sales, and whether you can compare this bug to other bugs of the same severity. Thus, at test IO we distinguish between three severity levels for functional bugs:
Low:
Minimal impact on the usage of the product.
The product shows unintended behavior, but the general usage is not affected.
Few users, products, or items are concerned.
A feature/piece of functionality is broken or unavailable, but an easy workaround solves the problem.
High:
Serious impact on the usage of the product, but the main functionality is intact.
A large number of users, products, or items is concerned.
Non-trivial functionality is broken or unavailable, and no workaround exists.
Important functionality is broken or unavailable, but a workaround exists (hence not a showstopper).
Critical:
The bug prevents the core functionality of the app/website.
A showstopper prevents the user from continuing the main process, e.g., checkout.
The bug causes a potential and notable loss of sales for the customer.
We've prepared a list of cases with fixed severity levels based on common assessments: Take me to the Bug Assessment Sheet! Please review the list carefully and check it regularly for future updates.
Content Bugs
Content bugs relate to the actual content of websites or apps: text, labels, pictures, videos, icons, links, data, etc. Hence, typical content bugs are:
Broken links or images (404s) (unless located in the navigation menu, header, footer, or breadcrumb navigation, which are low functional bugs)
Defective redirections, in general
Missing text, e.g. in an empty tooltip
Missing content, e.g. empty content area
Missing content, e.g. if 4 out of 5 icons have a tooltip, 1 doesn't
Missing translations, e.g. some buttons on an English website having French labels
Some products are missing in search results, but the search function itself works
Missing data
Please note that spelling mistakes are not considered content bugs on our platform and cannot be submitted as such.
Visual Bugs
Visual bugs relate to the graphical user interfaces of websites or apps, e.g.:
Layout framework problems such as misaligned texts/elements
A Responsive Design problem, e.g. an element is displayed on one mobile device but not on another
Text/elements unintentionally overlap each other
Text/elements are cut off
Upgrade of a content or visual bug to a functional bug
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 breadcrumb navigation. Such problems are typically Low functional bugs.
Repetitive problems
When content or a visual problem occurs repetitively, it may only be submitted once, even though each occurrence may have a different URL, link, picture, etc. This is also the case if occurrences are on the same page or different pages. This single bug report should state that other URLs, links, pictures, etc., are also concerned.
Individual bug reports for every occurrence of the problem must not be submitted and will be rejected. For example, only one report should be submitted for the following content issues: Some product pictures on multiple product detail pages of a webshop are broken, some download links for PDF manuals on multiple product detail pages lead to 404 pages, some product descriptions are in a different language than the rest of the webshop, some tooltips don't contain any information, some links that belong to the same group are broken, etc.
The following visual issues should only be submitted once: Some texts or images are larger than their boxes, multiple input fields are not large enough to hold their default texts that are not completely visible, multiple teasers unintentionally overlap other elements, etc.
For more detailed information about each bug type and their documentation on the test IO platform, please visit the following articles: