Test case choosing options
When creating or editing test runs, there are multiple options for choosing the test cases to include. This article explains the different selection options and their functionalities.
Include all test cases
The default selection when creating any test run is to include all test cases. With this option selected, all test cases from your project (or suite if your project has multiple suites enabled) will be included in the test run. Additionally, if you create new test cases within your project or suite, then these cases will automatically be added to your test run.
Select specific test cases
This option allows you to choose specific test cases or apply a filter to choose test cases based on the specified criteria.
With a filter defined, you have the option to do one of the following:
- Change your selection to match the new filter (this is the default Set Selection option)
- Add your filter to the test run’s current selection of test cases
- Remove the cases matching your filter from your test run.
Dynamic filtering
With a dynamic filter set, any new test cases added to your project which also match this filter will be automatically added to your test run. Dynamic filtering allows you to specify a filter for your test cases based on certain criteria. The filter dialog is similar to the dialog for selecting specific test cases, described above.
For each test run with a dynamic filter, you will be able to apply a single filter to your test run. You can also select additional test cases and sections using the left-hand area of the dialog. This manual selection will not create a filter, however. Cases will only be automatically added and removed from your test run based on the filter criteria set.
When viewing your test run, any newly-added tests are identified by the filter icon 
.
Additionally, if a test case is updated to no longer match the filter applied, the corresponding test will be removed from your test run.
Start and End dates for test runs
You can define Start Date and End Date fields when creating or editing test runs. These fields provide additional context on scheduling without affecting the run’s status or behavior.Key details
- Optional fields: Start and end dates are non-mandatory and can be left blank.
- Editable while active: These fields can only be edited while the test run is active. Once completed or closed, they become read-only.
- Inherited dates: If the test run is associated with a milestone, it will display the milestone’s dates unless specific dates are defined at the test run level. Run-level dates override milestone dates.
- Warnings: When setting dates, you’ll be notified if the run’s end date exceeds the associated Test Plan or Milestone dates. These warnings do not block the save action.
- Manual completion: Test runs are not automatically completed when the end date passes; users must manually mark them as completed.
- Reporting and API support: Start and end dates are included in relevant reports and available via the API.
These fields are also available when adding runs to a test plan. For consistency, they behave similarly to milestone date fields across the UI and are tracked in the audit log.