You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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.
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.
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.