How to replicate bugs in azure devops board ?

Question

I am new to azure deveops, just knows its basic but has not used it much till today. I am eager to learn this platform so that, I can contribute my POC from this platform. Help me understanding with this question.

Answer 1

Hi @Ajay Kumar ,

“How to replicate bugs in Azure DevOps Board?” can be a little ambiguous, so below are the two common meanings:

1. How to “reproduce/describe” bugs so others can replicate them (in Azure Boards)
2. How to see/track “bug work items” on the Board/Kanban/Sprint (board visibility/config)
3. Replicating a bug (capturing repro steps in Azure Boards)

To make a bug replicable by your team, create a Bug work item and fill in the Steps to Reproduce field with enough detail for someone else to recreate the issue. This includes:

• actions taken to find/reproduce the defect
• what you expected to happen
• what actually happened

Also, Azure Boards supports bug-specific fields such as:

• System Info
• Found In Build
• Acceptance Criteria

These help others understand the environment and conditions where the bug occurs.

Tip: If you don’t see effort-related fields on bugs, you may need to customize the Bug work item type so the fields you need are shown.

2. Making sure bugs appear on your Azure Boards Kanban/Sprint board

If your issue is that bugs aren’t showing up on your board views, these are the most common reasons:

• Bugs are limited by what’s assigned to the team’s Area Path and Iteration Path Work items must have the correct area path and iteration path associated with the team, or they won’t display.
• Board/Backlog level mismatch The board you’re looking at (for example “Features” board level) may only show certain work item types.
• You may be missing bugs due to team settings / bug visibility There’s a setting for showing bugs on backlogs and boards. Make sure your team has it enabled.
• Kanban limits and “load more” If there are too many items, you might only see up to the configured limit; use Show more items to load additional cards.
• Sprint pages only show Task/Requirements-level items For Sprint backlog/board, only work item types at the Task or Requirements level appear on Sprint pages.

References:

• Kanban and Board issues / troubleshooting
• What is configurable & boards setup
• Filtering Kanban boards
• “Why don’t I see all the work items on the Kanban board?” (limits & Show more items)
• Sprints overview & sprint visibility troubleshooting
• Show bugs on backlogs and boards
• Define/capture/triage/manage bugs (repro steps + bug fields)

Hope this helps!

---

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

In Azure DevOps Boards, bugs are tracked as a Bug work item type. A bug is used to capture, prioritize, assign, and track code defects.

A practical way to work with bugs is:

1. Create the bug
   • In manual testing, use Test Runner and select Create bug.
   • In exploratory testing, use the Test & Feedback extension and select Create bug.
   • If the team manages bugs with requirements, bugs can also be added from the product backlog or board.
   • If the team manages bugs with tasks, they can be added from the sprint backlog or task board.
2. Add enough detail to reproduce it
   • Use Steps to Reproduce to record the exact actions taken and the expected behavior.
   • System Info and Found in Build can be filled automatically when the bug is created through testing tools.
   • Add Acceptance Criteria so the team knows what must be true before the bug can be closed.
3. Track the bug through its workflow
   • In Scrum, bugs move from Committed to Done.
   • In Agile and CMMI, bugs are usually moved to Resolved, then verified and moved to Closed.
   • If the fix does not work, set the bug back to Committed or Active to reactivate it.
4. Verify and close the bug
   • A developer or tester tries to reproduce the issue again after the fix.
   • If the issue is fixed, close it with the appropriate reason.
   • If it is a regression, open a new bug and link it to the original with a Related link instead of reopening the closed bug.
5. Link the bug to development work
   • Bugs can be linked to builds, releases, branches, commits, and pull requests.
   • The Development control shows related builds, commits, and pull requests.
   • The Deployment control shows related releases.

If the goal is specifically to replicate or reproduce a bug, the key field is Steps to Reproduce. That field should include:

• what was done
• in what order
• what result occurred
• what result was expected

If the team uses the Basic process, there is no Bug work item type. In that case, bugs are tracked as Issues.

---

• Define, capture, triage, and manage bugs in Azure Boards
• Show bugs on backlogs and boards