Bug vs Defect vs Error vs Failure - is there are difference or are they all the same?

Bug vs Defect vs Error vs Failure - do you think there is a difference between each of these things or are they all the same?

Also, do you classify issue reports differently based on whether it was found in development (i.e. before a feature or change has been released) as opposed to something that has been found in production? For example, if an engineer is building a new feature and discovers an issue that doesn’t appear in production, do you categorise that issue as a bug or defect? And if an issue was discovered in production, is that categorised as something different because it is in the live environment?

While I encourage engineers to fix any issues they find straight away, whether they are in production or not, sometimes it will get put into the backlog due to conflicting priorities. I want to enable the teams to see what issues are in the current dev environment, that are not in production so when a release is done, they can see what issues are about to go out and how they will affect the quality of production.

2 Likes

I treat bug and defect as synonyms (maybe that’s sinful from ISTQB point of view :sweat_smile:), for errors and failures, they are different to me - errors don’t necessarily mean bugs they can just be technical information and failures I see that as something like environmental issues, unexpected outages.

4 Likes

I thus prefer to call these things “issue tickets”. And then class them as new or regression; a far more informational approach. For me at the end of the day, the priority of an issue and the source of the issue are more important than what we ultimately call them. It takes longer to prioritize and size an issue than you think, the older it becomes. So having regular combing or triages and pulling bugs found “in sprint” into the current sprint becomes a bit easier, than for bugs that escaped.

I thus make more noise about issues in the new feature, the priority is more important to me than what we call them. That was a dastardly good question though.

5 Likes

If you want to go by ISTQB standards then there is a fine difference between them. However once you actually go to the work field they are all and the same, an issue, a problem, somenthing that is not ok with the system.

There are some that ask such definitions in interviews, but I would rather prefer to see how a person thinks and can do then to have someone that can recite to me the ISTQB Curriculum.

5 Likes

Thank you everyone for the feedback! :slight_smile:

I like the ‘new’ and ‘regression’ options. I hadn’t thought about it like that but it makes sense.

3 Likes

In my experience: I would say it all depends on what development system you are working with. In an environment where you are testing builds, and working towards a fully designed product, there are only Bugs. and these bugs are classified depending on their type. Goal: Raise as many bugs as possible for the team to prioritise and fix for the next build while they add more features.

In a continually delivered environment where changes and new features are designed and added along the way. Usually to a system/product that is already in use. There are only 2 main classifications of an issue; “Bug” and “Defect”. Defects are raised against new features usually in a ticket system and bugs are sent back from the end users. Bugs would have a Caused by section to guide testers into not only checking the fix worked but also the functionality originally created that introduced this Bug is regression tested to confirm this still works as intended.

If this system also has a staging DEV/UAT environment. There is a need for a 3rd issue that represents Bugs found in staging this is a Staging-Bug. The idea here is that you’re staging team/automation/regression testing team discovers something before pushing to your Live environment but all incremental tickets have passed individual testing. This would then be flagged as an urgent bug as any Staging bugs should hold up deployments until actioned/resolved.

3 Likes

Errors aren’t necessarily the same as Failures although they (Errors) can & do result in Failures. Since Bugs is a colloquial term for Defects of a software OUT, they are a subset of Defects - a term that provides the vehicle to reason about problems in an engineering discipline agnostic manner i.e. equally applicable in/to OUT of a hardware, software & systems/hybrid nature.

1 Like