For project teams using azure devops and releasing regular updates to a software or service, there has to be a structured way of identifying and handling bugs. If bugs are just created by anyone and just added to the backlog without any reviewing process, this can quickly become unmanageable. Coming up with a structured plan may seem like a daunting task but it can be pretty simple. I will share an effective approach to bug tracking that I have used in my projects and maybe this will serve as a good foundation to come up with your own.
Organize regular Meetings
Things will go alot smoother if the team practices good communication and hold regular meetings. I like to schedule a “Bug Triage Weekly” and invite Process Owners and Product Owners, once a week, to give short updates and keep everyone aligned. This meeting does not need to be any longer than 15 min. If there are any technical requirements to discuss in detail, this can be handled in a separate meeting.
Bug vs. Change Request
When is a defect considered a bug? In general the main differences are as follows:
A Bug is a defect or malfunction of the intended functionality. (ex. the alert says “Test” but it should say “Test123”
A Change Request is a planned change to the intended functionality. (ex. the alert says “Test” but we want it to say “Test123” and flash red.
Who Decides it is a Bug?
Anyone can find and report a bug. However, before it is created as a ticket in Azure Devops it will need to be approved by the Product Owner.
Who Creates and Approves Bugs in Azure Devops?
The Stakeholders will manage creation of bugs. Once created, it will be approved by the Product Owner.
Azure Devops Best Practices
Bug Creation and Management
The minimum required fields should be defined and communicated with the project team. Filling these fields out properly will ensure that the team can have the best understanding of the current situation and how to approach a possible solution.
| Field, Group, or Tab | Usage |
| Repro Steps | Used to capture as much detailed information as possible so that team members can fully understand the code defect. Include actions taken to find or reproduce the bug and expected behavior. |
| System Info | Include any error logs or system information relevant to the bug (i.e Environment, Solution, etc) |
| Acceptance Criteria | Provide the criteria to meet before the bug can be closed. Before work begins, the acceptance criteria must be discussed. |
| Priority |
Priority 1: A critical business function or application is not working correctly or is not available to a majority of users. Priority 2: A high-priority business function is not working properly; functionality is limited or is not available for some users. A workaround or manual process is available Priority 3: A non-critical business function is not functioning correctly; or an individual or small group of people are unable to perform functionality that is not an everyday occurence. Priority 4: The issue does not affect core functionality or data. It is typically an „inconvenience“ or minor user impact. |
| Severity |
A rating of the impact of a bug or work item on the project or software system. For example: If a remote link within the user interface—a rare event—causes an application or web page to crash—a severe customer experience, you might specify Severity = 2 – High and Priority = 3. Allowed values and suggested guidelines are: 1 – Critical: Must fix. A defect that causes termination of one or more system components or the complete system, or causes extensive data corruption. And, there are no acceptable alternative methods to achieve required results. 2 – High: Consider fix. A defect that causes termination of one or more system components or the complete system, or causes extensive data corruption. However, an acceptable alternative method exists to achieve required results. 3 – Medium: (Default) A defect that causes the system to produce incorrect, incomplete, or inconsistent results. 4 – Low: A minor or cosmetic defect that has acceptable workarounds to achieve required results. |
Bug Status Workflow:
A Bug starts in the New state until it is confirmed by the Product Owner at which point it is changed to the Approved state. Bugs in the approved state are analyzed by the Bug Manager and once all required information is present and resources are identified, the bug can then be changed to Committed.
Work and tasks associated with the bugfix are delegated to project team members by the Bug Manager.
Once the bug has been resolved and the Product Owner approves the solution, the bug can be changed to the Done state.
I hope this helps you get a good picture of what is required to effectively manage bug tracking in azure devops. Feel free to use this as a basis for your own Bug Management Guideline!