Bugs and Defects.
What are they
&
How to Manage them
“It is easier to confess a defect than to claim a quality”
Max Beerbohm
Bugs vs Defects
In general terms: A bug is a programming error, a type of issue that occurs when a piece of software is created. Defects are those that are discovered after a software has been created. Bugs are issues that are exclusively discovered during the STLC.
Some things in life are matters of discussion and argument, some aren’t, some are facts.
One of those facts it’s that there's no software without bugs.
So given that , what do you do as a software professional? The answer can be seem very easy:
Bug exists = Bug is fixed
Easy and straightforward as it seems, in the real world this can be impractical and in some situations catastrophic . Bug tracking, debugging and fixing consumes resources.
Remember, you have a finite number of resources and theoretically an infinite number of defects, logical issues and errors.
Considering these factors one comes to the conclusion that the process of managing bugs should be more optimized, dynamic.. in simple words smart.
To achieve that you need to consider some factors such as what are my goals, do i need to catch up with the market, can i take a calculated risk, am i the big player and bugs don’t matter, are some bugs worth fixing?
What is the magic formula? If i have to give one i’d say
If you decide that a bug is worth fixing then you need to decide the priority based on the factors below by taking in mind the unbreakable codependent link between Severity, Impact and Occurrence whereas the overall result should be way lower than your Calculated Risk
Priority => Severity ⇔ Impact ⇔ Occurrence = < % Calculated Risk
At the end of the day though, this decision is based on one’s knowledge and experience, these data will just make the image a little less blur.
So let's break down those parameters..
Severity
An app has a lot of features and configurations. Tests were created to test these features. Some tests are more important as they test the fundamental and/or critical parts of the app.
If a bug has been found that blocks a step in an unimportant manner, meaning not on the critical parts, it can get labeled as "Blocker" but still won’t be fixed or it can be put in the backlog. If the result that you received does not prevent you from performing the step, but it causes another step to fail, then it gets labeled as “Critical”. Those bugs that have been identified as Critical but are still considered "Won't fix" by the authorities may receive priority "Trivial" status. Bugs that were identified as Critical on fundamental functionality need an immediate fix.
In general terms we have:
- Blocker
- Critical
- Major
- Minor
- Trivial
Whereas fixing them depends on where they were found and what is the impact mostly on User Experience which at the end of the day this is your main target without of course neglecting other aspects such as Compliance, Security etc.
Priority
Priority is not that straightforward as Severity is. It depends on the point of view. Something that is low priority from a Tester’s view point, from the Product view it could be Critical. Let me give you an example. You have a login page, the Tester noticed that the Login button is label as “Logan”. From a Tester's perspective this is something that needs to be reported as a bug of course and not as a suggestion but from the Product’s perspective this is Critical Blocker.
Why?
It affects the UX and the company’s integrity and professionalism. And that is why we have Product Owners and Product Managers deciding merging the technical perspective with the business perspective and decide what needs to be fixed