Functional bugs relate to the software’s functionality, such as a button that doesn't submit a form, an unresponsive search, or an app crash. If the website/app doesn't respond as expected, it may indicate a functional issue. Determining whether it's intentional or a bug can be challenging due to limited information on our customers' products. However, analyzing product behavior and making educated guesses based on experience can help.

When testing, check if the behavior is designed or broken by testing features individually and in combination. Consider customer intentions and provide evidence when claiming something is not working correctly. A webshop functioning differently than others doesn't necessarily mean it's broken. Report visual or content problems that hinder functionality as functional bugs.

The factors to consider while assessing the severity level must include the bug's functional impact, the extent of the problem, availability of workarounds, potential loss of sales, and comparison to bugs of similar severity. The severity level can be determined by assessing the relevance of the functionality in the context of the whole product, the number of affected users, the ease of finding a workaround, and the potential loss of sales. Comparing the bug to previously approved bugs can also help determine its severity level.

There is a list of cases with fixed severity levels that the above assessment scheme does not apply. The list may change over time, so it should be checked regularly.

Take me to the Bug Assessment Sheet!

Edge case bugs occur when a feature is used unusually. Relevant ones are forwarded as Low bugs, while most irrelevant ones are rejected.

Forced bugs resulting from non-typical behavior or special conditions are generally irrelevant to customers and are out of scope. Such behavior might trigger a serious warning from our side. Therefore, we suggest restraining yourself from submitting forced bugs.