Azure DevOps Test Suites Explained: Static vs Dynamic vs Requirement-Based
Understand the three types of Azure DevOps test suites — static, requirement-based, and query-based — with practical examples showing when to use each and how they affect test management efficiency.
Azure DevOps Test Plans supports three types of test suites. Choosing the wrong type creates maintenance overhead that grows with your test suite size. Choosing the right type almost manages itself.
The three suite types
| Suite Type | Populated by | Best for |
|---|---|---|
| Static | Manually adding test cases | Fixed sets of tests unlikely to change |
| Requirement-based | Linked to a work item (story/feature) | Traceability to requirements |
| Query-based | Work item query | Dynamic sets that change with your backlog |
Static suites
A static suite is a manually curated collection. You add and remove test cases explicitly.
When to use:
- Smoke test suite (fixed 10–15 tests run before every deployment)
- Exploratory testing session (ad-hoc set for a specific investigation)
- Partner-facing test suites (external stakeholders need a specific fixed set)
Creating a static suite:
- Inside a test plan, click + → New suite → Static suite
- Name:
Smoke Tests — Critical Paths - Click Add test cases and search by tag, title, or query
Maintenance burden: High if the suite is large. Every new test case must be manually added. Good for small, stable sets; poor for large evolving suites.
Requirement-based suites
A requirement-based suite is automatically linked to a single work item (a User Story, Feature, or Epic). Test cases that have a Tests link to that work item appear in the suite automatically.
When to use:
- Sprint-by-sprint test management (one suite per user story)
- When you need a requirements traceability matrix
- When stakeholders want to see "what tests cover this feature?"
Creating a requirement-based suite:
- Click + → New suite → Requirement-based suite
- Azure DevOps shows a list of work items
- Select the User Story or Feature this suite covers
Test cases appear automatically as you link them to the requirement.
The traceability benefit:
User Story #312 (Wishlist feature)
└── Requirement-based suite
├── TC-201: Add item to wishlist ✓ Passed
├── TC-202: Remove item ✓ Passed
├── TC-203: Wishlist persists ✓ Passed
└── TC-204: 50-item limit ✗ Failed → Bug #891
Coverage: 3/4 passed (75%)
The coverage percentage is tracked automatically and visible in the Progress Report and Requirements tab.
Query-based suites
A query-based suite runs a work item query and shows all matching test cases. The suite updates automatically whenever the query results change.
When to use:
- Regression suites (all test cases tagged
regression) - Priority-based execution (all P1 test cases in current sprint)
- Scope-based execution (all test cases for a specific component)
Example query for a regression suite:
Work Item Type = Test Case
AND Tags CONTAINS "regression"
AND Area Path UNDER "ShopFlow / Checkout"
AND Priority <= 2
As new test cases are tagged regression and assigned to the Checkout area, they automatically appear in this suite. No manual maintenance required.
Combining with iterations:
Work Item Type = Test Case
AND Tags CONTAINS "sprint-7"
AND State = Ready
This automatically shows all test cases planned for Sprint 7, removing the need to manually add them to a sprint suite.
Recommended suite strategy
A practical structure for a 2-week sprint:
Sprint 7 Test Plan
├── [Static] Smoke Tests (15 critical path tests)
├── [Requirement-based] User Story #310 — Multi-room Booking
├── [Requirement-based] User Story #311 — Guest Profiles
├── [Query-based] Sprint 7 Regression (tagged "regression", P1/P2)
└── [Static] Exploratory Sessions (ad-hoc)
This structure gives you:
- Fast smoke tests before each deployment cycle
- Full traceability to requirements
- Auto-updating regression suite
- Flexibility for unscripted testing
Common errors and fixes
Error: Requirement-based suite shows 0 test cases even after linking Fix: Test cases must be linked with the Tests link type (not Relates To or Parent). Re-open the test case → Links tab → check the link type.
Error: Query-based suite is slow to load or shows stale results
Fix: Very complex queries with large result sets can be slow. Simplify the query (add more specific conditions) and avoid using EVER operators which scan full history.
Error: Test cases appear in a suite but are greyed out Fix: Greyed test cases are in Closed state. Filter the suite to show only Active/Design/Ready state test cases, or reopen the closed test cases.
Error: Requirement-based suite doesn't update when new test cases are linked Fix: The suite refreshes on page load. If new test cases aren't appearing, check that the link type is Tests (not another link type) and refresh the page.
Stay ahead in AI-driven QA
Get practical tutorials on test automation, AI testing, and quality engineering — straight to your inbox. No spam, unsubscribe any time.
Discussion
Sign in with GitHub to comment · powered by Giscus