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.
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.
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)
So really it’s totally up to you, so… some questions you might ask yourself;
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)
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.
FYI, we use the following distinction:
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
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
@Rachel Wright (Jira Genie), @Billy Poggi (AUG NOVA, DC), and @Dana Jansen (Confluence Queen) are just some of the folks that lead one of the world's most active Atlassian User Group (AUG)....
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs