Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.

Feature Request: Tags


I searched the forums and saw this feature request before, but I just wanted to echo it. For my company’s TestRail workflow, it would be great to be able to apply multiple tags to a test case. These tags would mainly be useful for searches.

The tags would then be searchable when generating test runs. This would help us greatly when we need to narrow down the test runs to just a few areas of the product.

Currently we are using a text field for tags. This is problematic. Typos could be introduced during tag input. To combat this, we were going to put all the appropriate Tags in the Custom Field description, but found there is no way to format this text. On top of all that, we still can’t search for these tags when generating a test run.

We hope to see tags in the product soon!



Hi Will,

Thanks for your posting. We are considering supporting tags for test cases for a future update and it’s likely that we will have this eventually. TestRail’s next update will also allow you to select test cases for a run based on the case attributes and this will also work with string fields (so you can select cases for a run that contain a specific string in a string field).



Awesome, thanks Dennis!


Is tagging done with the latest release?



Yes, tagging (or the more generic multi-select custom field which is used to implement tagging) is available since TestRail 2.7:

An example can be found in the blog post above and we are also happy to help in case you have any questions. You would just need to create a multi-select custom field under Administration > Customizations and add your list of allowed tags to the options of the custom field (Add Project & Options link above the Save Field button).



Thanks for the reply!
Its great to have this as feature. But still what I could not achieve is search by specific values. for example I have 3 tags A, B and C used in different testcases with different combinations, but for new test run execution I wanted to pick only case that has A. I don’t see a direct way with filtering. In fact, filtering is nothing but sorting on that column, and thus i can see all test cases under given suite in sorted order and then manually has to pick cases that has tag-A.
More on than I can’t even search multiple suites with given tag.

Can I achieve this by some mean, or is that a restriction?



Thanks for your feedback. If you’ve used a multi-select custom field for implementing the tags, you can filter for test cases based on those tags on the Select Cases dialog (via the ‘select cases’ on the test run or plan forms):

Is that what you are looking for?



Yes, this will help!
BTW, I found another discussion thread talking about the same tagging feature:
In case people want to refer it for any future reference.


Good to hear that this works for you!



I’d like to ask for a better way of managing tags. The multi-select custom field option is functional, but isn’t very flexible when you consider a large or constantly growing/changing list of tags. When that’s the case, keeping the list of multi-select options organized is the only real way to ensure people actually use the tags (or can even find the tag they’re looking for).

And trying to do that via one or more custom fields where the admin is responsible for specifying the ID for each value (and where the ID plays the pivotal role in connecting the tag to the case, suite, result, etc.) is a bit of a nightmare.

This is really a UX/UI request at it’s core since the concept is already there; it’s just the interface that isn’t very manageable. Shooting from the hip, I’d say take the onus off the admin to manage the ID’s for the field options (in fact get rid of the custom field requirement altogether) and let admins just add “tags” to some kind of tag list or tag management function/page. Then give users the ability to select tags when creating/modifying cases, suites, reports, etc. and make sure the way the tags are presented to users is intuitive and easy to digest (i.e., easy to find a particular tag or verify a tag doesn’t exist yet).


Hi Scott,

Thanks for your posting. Yes, I agree that the current approach can be improved and we already had this on our feature request list. For example, it might make sense to look into supporting an additional custom field type which does not work with a fixed list of values but is more flexible and works more like a standard tags field. We will make sure to review this again for a future version, thanks for your feedback!