How do you log defects - prior to release and in prod?

[Karmen Mattsen]

How do you log and manage defects (aka bugs) detected prior to releasing to production?  Do you create a 'bug', create a task in the story, create a sub-task, use a custom issue type (e.g., defect), or something else?  Do you use the same process for logging bugs found pre-prod as those that have leaked to prod?  If so, do you need to differentiate between them with an environment field to manage them and collect metrics?

We want to be able to report on bugs, know what environment, root cause and other information.  Right now we capture bugs leaked to production by creating a bug, but wwe have no custom fields, so are wondering if we should use this same issue type for bugs found prior to releasing to production or something different that better ties it to the story/sprint. 

What are you doing / what do you suggest?  Thanks for your help!

[Muthu Thiruppandy · Accepted solution]

There are many different ways to track the bugs prior to releasing to production.   My suggestion based on our experience:

 1. Track the pre-production/Development/sprint bugs using 'Bug issue type' similar to Production Bug

2. Use a custom field to differentiate the type of Bug.  something like a list field with -Production Defect, - Internal Bug  or any appropriate name

3. If you are already using Customer or Client fields while capturing the source who reported, use a customer 'Internal' .  this is not needed if there is no need for you to track the Customers

4. Use the to be released version as the affected version

5. If you would like to track the requirement source, use appropriate links to the Story ( caused by/Causes)

5. Make sure your metrics for escaped defect/leaked defect exclude the internal bugs

This will also help with other Metrics reporting an analysis of the quality of internal development/testing. 

The known issues, bugs not fixed before production release, can be part of the Release notes

[Karmen Mattsen]

Thank you, Muthu!  This is helpful as it's one of the options we're considering - using 'bug' and creating custom fields for data like root cause, business capability.  We probably would differentiate it from production leakage by capturing the environment (e.g., prod, QA, Stating). 

I'm curious if others find it to be more helpful to create a sub-task and use a label (e.g., bug) , or create a different issue type (e.g., defect) to filter for the team and for reporting.

[Karmen Mattsen]

Does anyone else have a different / better way?  I realize there are many ways to do most things, this being no exception, and am curious if there's a typical way that's best.  Thanks!

[Lynn Chin]

Same here @Karmen Mattsen

I know the post has been hanging around for awhile. I wonder if you have heard any better or different way of doing things here? 

I think it's interesting to know more too!