nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Huy Trinh_iv0ne7

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.

Thanks.

Comments

Brad_Ledford

Have you gone through the official guides here: https://www.atlassian.com/software/jira/guides

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!

Ajit Rajput

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server