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

Feature request: "Test Suite"-level properties


Besides “Name” and “Description”, it would be useful for us to have test suite wide properties (instead of being limited to test cases). In fact, we would like to add custom fields to Test Suites.

I don’t believe this is currently possible (not through the interface or the mini api as far as I can see).

Our test suites are organized in a way that their test cases cover individual components (or area of test) of our Product. It would be useful for us to be able to manipulate test suites as a whole (moving, reassigning, grouping etc…).



Hello Rami,

Thanks for your feedback and for the suggestion. I agree that this would be useful to have and I’ve added it to our feature request list. You could already use the Description field to store meta information in the meantime, but it wouldn’t provide you with a way to manipulate the data of course. Could you share a few more details on what you are trying to accomplish by manipulating and grouping the test cases based on meta data so we have a better understanding of the use case?



Hi Dennis,
Basically, because our test suites cover components of our Product, we would benefit from being able to categorize those test suites/components, for example “Frontend” vs “Backend”. I would be able to create Test Plans/Runs based on these properties.
Another scenario is prioritization. We’d like to have 2 different priority scopes. The priority of a test case is limited to the scope of it’s test suite, not the overall Product. The priority of a test suite, however, is at the Product level.

Say you have this structure:

TC A.1 (priority: high)
TC A.2 (priority: medium)

TC B.1 (priority high)
TC B.2 (priority low)

I’d like to be able to prioritize TS B so that BOTH TC B.1 and TC B.2 get executed before TC A. So if I assign the following priorities to the test suites:

TS A (low)
TS B (high)

This will be the order of test cases:

TC B.1
TC B.2
TC A.1
TC A.2

Now, this can be accomplished artificially by the administrator (when creating runs) as long as the info is in the test suite to begin with, I guess that’s more realistic than the auto-recalculation of priorities.

Hope this clarifies things more. “Type” and “Priority” are the two main properties we could use now, but I could definitely see the need for custom field support.




Hello Rami,

Thanks a lot for the clarification, that’s very useful. I agree that having attributes for test suites could be useful (especially for selecting test suites for test plans) and we’ve added it as a feature request. Just let me know in case you find any additional use cases for your particular workflow for this.