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

Feature Request: Custom Fields for Project and Test Run


#1

We are using TestRail with an automation engine. We would like the ability to pass project level information for every test case execution.

Example 1 Project Custom Fields: (repository, change set)
This would allow us to identify a repository for all automation assets. In addition we would use a custom field to identify the branch or change set desired in the repository. All test cases would have a relative reference to a script within the repository.

Example 2 Test Run Custom Fields: (build id, phase, path)
Allowing for custom variables in Test Runs would allow for us to create required fields for identifying the build number, process phase and path to target software. These fields would allow us the ability to configure our automated tests to pick up the proper version of target software and install it.

The idea is that the test result object would have linkages to the parent fields for us to gather the information when executing automated tests.


#2

Hi Seth,

Thanks for your posting! Custom fields are currently supported for cases and results but extending this to other entities is already on our feature request list and I’m happy to add another vote. You can already use the description field of a project/run etc. to store additional details and you could even look into storing structured data (e.g. as JSON or another format) in these fields if the projects are (mostly) for automated tests.

I hope this helps!

Cheers,
Tobias


#3

I’d like to add my vote for the ability to add custom fields to TestRail Runs and Projects as well.


#4

Thanks for your feedback, Joy!

Cheers,
Tobias


#5

Please add another vote for this feature. Maybe there is a better way of doing it in Testrail but this is what I am looking for:

Reporting defects to our Jira should be as easy as possible, and I hope that I can predefine some required fields for Jira on Test Run level and possibly having no need for the push defect form at all. In detail, these are e.g. Affected Versions, Labels and some custom fields.

The workaround with putting this data in the description field would be ok for starters, but usually we use it for a “real” description. How can I access the description from the Jira defect plugin?

Thanks a lot,

Ben


#6

Hi Ben,

You can add additional JIRA system and custom fields to the Push Defect dialog. On Administration > Integration, you can enable some system fields (Affects Versions, and others) directly by switching the field from off to on. You can also add custom fields to the dialog and the documentation for both system fields and custom fields can be found here:

http://docs.gurock.com/testrail-integration/tools-jira-fields#displayed_fields
http://docs.gurock.com/testrail-integration/tools-jira-fields#custom_fields

I hope this helps!

Cheers,
Tobias


#7

Hi Tobias,

I was not quite clear about my intentions. I know about the possibility to add custom GUI elements. By predefined fields I mean the contents of these fields. Let’s say I can define a Test Run with the following “properties”:

Affected Version: 8.4.1_My_Company (the customers version in Jira)
Customer: My Company (we use this for accounting in Jira)
Label: My_Company_Test (This is our workaround for only having one large project in Jira…better don’t ask why…)

Pushing a defect would populate the fields in the GUI with these prefined properties and the defect ends up in the correct structure in Jira.

Custom fields for a Test Run where the properties could be defined would be perfect, but using the description field would be ok due to missing alternatives. So I hope it is a bit clearer what I try to achive.

Best,

Ben


#8

Hi Ben,

For fields of type dropdown, TestRail automatically remembers previously used values so you wouldn’t usually need to define defaults. The moment you push a field, TestRail remembers the dropdown values per TestRail project & user by default and would restore this the next time you open the dialog.

Cheers,
Tobias


#9

Hi Tobias,

Ok, I will check if we can get along with Dropdown fields. For historical reasons, we use Jira in many strange ways, with no chance to change that in the near future. That’s why we have a really large bunch of Affected Versions, Labels and Epics. So I am a bit sceptical if that really works out in every day usage. But I’ll try!

But feel free to add my vote for custom fields in Test Runs :wink:

Thanks for your Support!


#10

Thanks, Ben :slight_smile: Please let me know in case any further questions come up, happy to help.

Cheers,
Tobias


#11

Hi Tobias,

today I tried to add some functionality to our customized JIRA-plugin. As I have mentioned I need to select the “affected version”, the “label” and the “epic” to make sure that the defect ends up at the correct position in our JIRA. As the “affected version” was already supported as dropdown (only a few minor adjustments were neccessary) the hard part was to get the correct list of labels and epics in two more dropdowns to have the selections remembered over subsequent calls of the defects dialog. I failed awfully with that, as JIRA appears not to have the means to easily get that information through their API.

So I am back to the idea, to set the information I need in the description field of the Test Run in a structured form. I have had a closer look at what the context object has to offer, and voila, there is some information about the Test Run (like id and name), but unfortunately not the description.

What I then did feels very ugly: using the Test Run ID, I have called the testrail API to get the Test Run description(!!). Well, it’s working but that cannot be the right thing to do, as there must be some much cleaner way to get the description with some undocumented method. Do you have any hints?

Best,

Ben


#12

Hi Ben,

Thanks for your feedback! Using the API is actually a good idea and this would be forward compatible with future TR versions and using an undocumented API inside TestRail wouldn’t work well in the long run. So, I would recommend keeping this as is especially since it’s already working. Please let me know in case you have any further questions or feedback, happy to help.

Cheers,
Tobias


#13

Hi Tobias,

What do you think about just adding the Test Run Description to the context object, which already includes Id, name and some other information about the Test Run? I think that would be the cleanest/easiest way for the moment. When using the API call I need to hard-code url and authentication information in the plugin, which I usually try to avoid.

Best,

Ben


#14

Hi Ben,

Yes, this makes sense as well of course and we are happy to look into this for one of the next versions. Thanks again for your feedback!

Cheers,
Tobias


#15

Add my vote too.
I want to use it with automated tools, so I would like to be able to add a custom field to a Test Suite where I could record the automation script name for that suite.


#16

Thanks for your feedback, Simon! You can also look into using the description field of the test suite/run to store additional context details in the meantime.

Cheers,
Tobias


#17

Bump for this request.

I would like the ability to define custom fields which are enforced in a similar way that test case fields are.
Simply to reduce the loss of data that is not always inputted with a free test field.

Additionally making these test run requirements differ between projects would help.

I am currently trying to make do with the free text description.

An alternative approach which may also have benefit is the ability to template the default text of a test run description. This means for my use case, all of the fields that im interested in are present to prompt my team to input a relevant level of information into the description.

:slight_smile:


#18

We would like the ability to add a new Field to Test Runs i.e., on the Edit Test Run page we would like a new/second description box labeled ‘Overall Results Description’.

Would the ability to have a custom field for Test Run allow us to do this?

If so please also add our vote to this request.

thanks,
Reagan


#19

One more vote for a custom field to the test run. I need to save the branch name the automated test ran against.


#20

Please make this happen. I need to add tags and Commit Hash specifically for automated testing.