Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

New to JIRA - Looking for best practice implementing JIRA for bug tracking

Hello all,


I am a newbie to JIRA. Our organization currently is using the product as an issue ticketing system. Based on my initial research, the product is best designed as bug tracking. 

I would like to get some ideas on best practices for implementing JIRA for defect tracking of bugs for our internal custom software. 




Have you gone through the official guides here:

These have been very valuable to me over the years in trying to get a sense for how Atlassian expects you to use their suite.

Good luck!

Here is my experience from implementing standard Bug workflow on large DC instance:

With organizations having multiple quality systems (viz. HP QC, JIRA etc.) and projects/teams using either/all of these systems, experience non-uniform defect life cycle which creates inconsistent quality processes, lack of corporate-wide visibility into quality performance, and create barriers / reduce flexibility to configure these processes as business challenges evolve. Hence implementation of such standardized Defect Life Cycle ensures that the process is uniform across the organization. 

Hence it is important to bring them under a standard operating model (atleast for defects tracking). The role of quality/engg practice team should take the primary role here to design, guide, train and create awareness of standardization in bug tracking across the organizations. 

Standard Workflow Templates

You as JIRA administrator would need to have atleast 2 or 3 standard bug workflow templates to which the projects should be associated with. These workflows should meet majority of teams/projects requirement in terms of tracking the defect life-cycle

Capture Key Attributes

Make sure the key attributes w.r.t. defects are captured during the lifecycle stages. These attributes could be :

* Root Cause (drop-down list),

* Source File/Location (text field) - Source artifact where defect is found.  

* Environment (dropdown field - values=DEV, SIT, UAT, PROD)

* Testing Phase (dropdown list - Code-Review, Unit Testing, Performance Testing etc). This will help to capture phase where defect has been identified

* Ownership (dropdown list - values=IT, Business etc) - This will help to segregate the ownership of defects. This will help reduce frictions happening between cross-functional teams on who owns the defect.

* There is always a confusion over defect Priority and defect Severity. Make sure you address those. 

Data Validations

During the workflow state transitions or defect closure make sure you apply conditions, validators or post-functions to ensure data-consistency. For ex: The "Root Cause" field may be not-known when defect is created, but when defect is being marked as closed, the developer/tester should know the Root Cause by that time.

You may want to apply role-based permissions on defects - if needed. However the suggestion is to keep it as simple. 


All of these have helped me to large extent to get consistent defect management, consistent key data/metrics to identify the quality of deliverables across the organization.

For teams, they all now speak same language, getting more visibility on their own deliveries and key metrics - to showcase or work upon continuous improvement

Hope this helps. 


Log in or Sign up to comment