what is the difference between a bug and a defect.

Amy Ikenn April 20, 2016

My team has both available and I need to advise them on when to use each.

7 answers

4 votes
Steven F Behnke
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 20, 2016

Bug is included by default, defect must be a custom issue type.

When I've used those, a Bug was a standard issue type, and represented Bug Reports. A Defect was a subtask type and was used when the manual QA team found a bug in a story or feature.

We can only guess why it's implemented in your system.

3 votes
Phill Fox
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 20, 2016

Some organisations define bug as anything found before release and defect as anything found after release. But other organisations use the exact opposite. So the decision is entirely down to your organisation on which makes most sense for your situation.

Whichever you choose make sure you police the usage to make sure that the users are using the right one.

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 20, 2016

It's up to you really!  If you can define a useful difference, then use both.  If you don't see any difference in your processes or terminology, then go ahead and delete the one you don't like.  Bear in mind that JIRA configuration is hung off issue type, so it can be useful to have two types.

There's a common tendency to call "issues found during testing" defects, and bugs are more "argh, it did the wrong thing in production", but it really is up to you how you define it.  In that scenario, you would do things like record the test plans against features, and regions or business impacts on bugs (hence the different issue types)

 

0 votes
thomas menzel December 1, 2019

(to me) they are the same except that defect is a more formal and maybe a bit more general term: ie, bug tends to denote programming errors whereas defect can be anything that's not working properly

just decide in the team how u want to use them, but that might be a bit late by now

thomas menzel December 1, 2019

just found this: https://paton.io/defects-vs-bugs-and-jira-6e14116b21b5 which explains it in more detail

0 votes
BenP
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 20, 2016

FYI, we use the following distinction:

  • Bug: A problem on released software, that requires changing code (to be built & deployed/released again) in order to resolve it
  • Defect: a problem on released software, that can be resolved without requiring a code change (new build & deploy)
  • Test Issue: anything (defect / bug / question) that is raised during Test, before a feature is released. 

 

information when a problem is reported by a customer, is always captured as a Defect..
until someone capable of qualifying it, converts it to a Bug  

0 votes
Deleted user April 20, 2016

So really it’s totally up to you, so… some questions you might ask yourself;

 

  • Do we find any value in knowing whether a problem was found before or after code has been released? (Most companies would probably say yes, but it’s up to your company to say yes or no)

 

If the answer is yes, then the question is how do you want to track development (pre-production) errors. (This assumes you will choose to call production issues Defects or Bugs and track them as separate JIRA issues)

 Additional thoughts/Options;

Some folks report these 'errors' as subtasks to the original issue. The thought being the issues is not “Done” and ready for release to Production until it passes QA (or “all subtasks are completed”)

Advantage: Easy to enforce “All subtasks need to be completed” before moving to a Done status.

Disadvantage: Reporting/metrics is not that easy and sometimes a QA issue is a low enough impact that the story can be released to production anyway. Now what do you do with the problem that’s left?

 ----------------------------------------

Others go with the separate issue type and link it to the story that it impacts. Now you have to check to insure linked Errors are completed before a Story is released, or that they have been identified as so small it should not hold up the release.

Advantages: Easy to generate reports and metrics, errors can be identified as bad enough to prevent release or not, easy to require a link to the source story.

Disadvantages: Not so easy to automatically enforce the rules as to whether a story can be released, especially in the Cloud.

 

I’m sure others can chime in on this, just thought I’d go a wee bit beyond “it’s up to you”. Hope this helps on the “advise them” part.

 

Cheers!

0 votes
MattS
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 20, 2016

It's all about tracking work items. Whether you call it a Bug or Defect, it's work that has an unexpected (and unwanted) aspect to it

Suggest an answer

Log in or Sign up to answer