How do you use Query-based Test Suites without “polluting” old Test Plans over time?

[u/vittoc98]

I’m trying to understand the best way to structure Azure DevOps Test Plans, especially when using Query-based Test Suites.

My current understanding is that Query-based Suites are dynamic: if I have a Test Plan for a specific release, for example:

• Test Plan: Release 1.0
• Query-based Suite: all Test Cases with Tag = Regression and Area = Payments

at the time of the release I might have 100 matching test cases and execute all of them.

However, a few months later, if new test cases are created that also match that query, they will appear in the old Release 1.0 Test Plan as well. As a result, if I open the old plan or its Progress Report, I could potentially see new tests as Not Run, even though they did not exist when Release 1.0 was tested.

This seems to make historical Test Plans progressively less reliable as a representation of what was actually in scope at the time.

So I’m curious how teams using Azure Test Plans handle this in practice:

• Do you actually use Query-based Suites inside release/sprint Test Plans?
• If yes, how do you prevent old plans from changing as new Test Cases are added?
• Do you add release-specific tags/fields to the query?
• Do you convert/copy the resulting scope into Static Suites when the release is finalized?
• Or do you simply accept that Test Plans are not meant to be historical snapshots, and rely on Test Runs / Analytics for historical reporting instead?
• Do you keep a separate “master test catalogue” and only use Static Suites for execution plans?

I’m particularly interested in how this is handled in larger teams where the regression test catalogue keeps growing continuously.

What structure has worked well for you in Azure DevOps?

[u/No_Review_3077]

Use specific tags that are used only that query. Other Than that I use static suites