A bug is a software related issue. If something on a website or in an application is not working as it is supposed to, this “error” is called a bug.
Here at test IO we use the terms “functional bug”, “usability suggestion”, “content bug” and “visual 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.
- It’s a valid usability suggestion if the proposed change enhances the usability of an existing functionality for a major group of users substantially and if cost vs. usage is justifiable.
- A suggestion could be to extend or simplify existing features or changes that reduce the amount of work and duration for users.
- Use the product like a real user. When something makes you wonder or seems counter-intuitive, it’s an indication that it could be improved.
- Justify your suggestion and provide a concrete solution.
- Problems related to the content of a page/app and not to its functionalities.
- Everything that can be fixed by replacing text, code, data, tags, or files with their respective equivalent and what does not block a functionality of the product.
- Examples: Broken URLs; missing pictures, tooltips, or data; dummy text in live products; shop products carrying wrong tags; empty, missing or wrong page content; content that you can tell was forgotten to be implemented or removed
- Problems related to the visual representation of the product and not its functionalities.
- Examples: Misalignments of graphical elements, unintentionally overlapping elements, cropped text, unintentionally cut graphical elements or text, HTML or CSS problems, responsive design problems, any static visual problem
- Broken GUI functionality that blocks the functionality of the product and problems where functions should lead to a visual change are considered functional problems.
- Orthographic problems with e. g. spelling, grammar, and typography.
- Orthographic problems are not content bugs
All bugs reported must be completed on creation and comply with our “Standards of Quality” or they will be rejected by the team-leader. The team-leader might also request additional information on bugs to verify it.
If this is the case you bugs will show on your dashboard listed under “bugs that need attention”, if you don’t give the requested feedback within 18 hours the bug will be rejected.