Using Linked Work Items to Show Which Test Cases a Bug Blocks
Your team uses Azure Test Plans. You need to ensure that testers can easily see which test cases are blocked by a known bug. What should you do?
Quick Answer
Linking test cases directly to the bug in Azure Test Plans, then building a query for linked work items, gives testers a live, filterable view of exactly which test cases that bug blocks — a dynamic approach that doesn't require duplicating or manually reorganizing any existing test artifacts.
⚠ Common exam trap
Many candidates confuse 'marking a test as blocked' (a manual status change) with the proper traceability approach of linking work items, leading them to choose Option D or B instead of leveraging Azure DevOps' built-in query and linking capabilities.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Link test cases to the bug and create a query for linked items.
Azure Test Plans allows test cases to be linked directly to bugs via work item linking. By creating a query for linked items (e.g., a shared query that returns all test cases linked to a specific bug), testers can instantly see which test cases are blocked by that known bug. This provides a dynamic, filterable view without duplicating or reorganizing test artifacts.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure the test plan to show only failed tests.
Why it's wrong here
Filtering the test plan to failed tests only reports execution outcomes, not the dependency between a test case and a known bug, so blocked cases stay invisible. It is tempting because outcome-based filtering genuinely helps triage failing runs during active test execution. Blocked status instead requires linking the bug to the test case, letting testers see it through the associated work item.
- ✗
Create a test suite for each bug.
Why it's wrong here
Azure Test Plans already tracks blocked status through test case outcomes and bug linking, so grouping cases into per-bug suites adds no blocking visibility and fragments your suite hierarchy. Suites exist to organise tests by requirement, sprint or configuration for execution and reporting; a per-bug suite would be the right structure only when you need to run that bug's affected tests as one unit.
- ✓
Link test cases to the bug and create a query for linked items.
Why this is correct
Linking each blocked test case to its bug creates a traceable relationship, and a work item query filtering on linked items surfaces those test cases, giving testers a clear view of what the known bug blocks.
- ✗
Copy the test case and mark it as blocked.
Why it's wrong here
Copying a test case creates a duplicate work item with no link to the blocking bug, so testers cannot trace the dependency. Duplication suits branching scenarios where a variant must diverge permanently. Here the requirement is a status flag on the existing test case, which the correct option sets directly.
Go deeper
Related to this question
Learn chapter
Implementing Work Item Management and Agile Planning
Key term
Bug
A bug is an error, flaw, or fault in software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
Key term
Work item
A work item is a digital record in Azure DevOps that tracks a single unit of work, such as a task, bug, or user story, helping teams manage and monitor their progress.
About these practice questions
This AZ-400 question is part of Courseiva's 696-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Match each Azure Test Plans concept to its definition.
medium- ✓ A.Test Plan: A container for test suites and test cases that specifies test settings and test configurations.
- B.Test Suite: A set of steps and expected results to validate a feature.
- C.Test Case: A collection of test cases grouped together for execution.
- ✓ D.Test Run: An execution of a set of test cases on a specific build.
- ✓ E.Test Point: A combination of a test case and a test configuration.
Why A: In Azure Test Plans, a Test Plan is a container for test suites and test cases with settings. A Test Suite groups test cases. A Test Case has steps and expected results. A Test Run is an execution of test cases. A Test Point is a test case with a specific configuration.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.