Functional Bugs

Functional bugs are related to functionality. Examples: a button doesn’t work, the search doesn’t react to the user input, the app crashes.
Every time you click and the website/app doesn’t respond as it should, it might be a functional issue. Check with the below assessment scheme to determine if your observed behavior is intentional or actually a bug.

How to 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 how it has been implemented.
  • Find evidence that something is not working as it should. Support your claim.
  • Example: A webshop functionality works differently than in other webshops you know. That doesn’t mean the functionality is broken. The client can implement their product however they want.
  • Example: You claim a form field is not validated and it’s a bug. Is there any indication that they intended the field to be validated? Provide evidence by showing that the field is validated in some cases but not in others. If you don’t provide evidence, it’s an unproven claim.
  • A visual or content problem becomes a functional problem when it hinders a functionality and thus be submitted as a functional bug.
  • A piece of functionality works the same way in whatever scenario and regardless of how often you reproduce it? Then it’s probably intended (not a bug) and you just suggest a change (Usability suggestion).

Severity Assessment

Functional bugs have three severities:

Low Low: Minimal impact on user experience
High High: Serious impact on user experience, but doesn’t prevent the function of the app or website.
Critical Critical: Preventing a main function of the app or website, causes a potential loss of income for the company running the app or website, e. g. an app crash.

Please note: Even though you might be able to select a severity in the bug form, it might be out of scope. Always check the scope of the test.

Common assessments

We have a list of common assessments that you should consider to make the right decisions. The list will be updated regularly over time. Take me to the list!

Edge case bugs

An edge case bug is a bug that only occurs due to nontypical user behavior or special conditions. Forced bugs are edge case bugs. Here are some examples:

  • Instant actions, such as minimizing an app immediately after clicking on a button
  • Tapping on multiple elements at the same time
  • Fast-paced clicking on a button multiple times
  • Repeatedly doing the same thing, e. g. opening and closing menus
  • Any bug that only occurs after an uncommon set of actions

Most edge case bugs are not relevant for our customers and will thus get rejected by team leaders. Only relevant and crucial edge case bugs will be forwarded to customers.

Legal issues

We are not legal advisors, so any legal problem is not a valid bug and is out of scope. Furthermore, the severity of a bug is not determined by legal provisions, frameworks, or standards.

Security issues

Security-related problems (including XSS attacks) are not considered as functional issues. If a customer is interested in this topic, a specialized security-focused test will be run. In all other cases, security-related problems are out of scope.

App crashes

Critical issues like crashes have to contain crash logs as part of the documentation. Please note that the video that documents the crash has to correspond to the attached crash log, i.e. timings must be coherent. This goes also for reproductions of those bugs.

Application blocked by SmartFilters or virus scanners

If the execution of an app is blocked by a smartFilter or virus scanner, it is not a bug, especially if it is a staging environment or a beta version of an app.

%d bloggers like this: