Skip to main content
Back to blog

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.

InnovateBits4 min read
Share

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 TypePopulated byBest for
StaticManually adding test casesFixed sets of tests unlikely to change
Requirement-basedLinked to a work item (story/feature)Traceability to requirements
Query-basedWork item queryDynamic 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:

  1. Inside a test plan, click + → New suite → Static suite
  2. Name: Smoke Tests — Critical Paths
  3. 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:

  1. Click + → New suite → Requirement-based suite
  2. Azure DevOps shows a list of work items
  3. 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.


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.

Free newsletter

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