Thank you for your reply and apologies for the delay in getting back to you. I don’t think that I would be changing the test case each time, I think it would be more specifying it in the results. I’ve looked at adding a custom field to the results, which I think is going to be the best way to do this, but have another question. I would like very much that the build is available as a drop down, and that when a build is triggered in our build system (we use Jenkins) that the list is updated via the api. Is this something which would be possible? Or give the way the field is managed, will it cope with an ever growing list, or would it be better to have it as a plain text field? I’m thinking that it probably wouldn’t be possible to keep the list maintained, as would it affect the results if we removed older builds periodically to make it easier to use for manual testers? I would have to have a different field per project to ensure only the correct build options are presented.
With regards to baselines, I understand now that this is to ensure integrity between test case and test runs, so we know exactly what version of the test case was used for that particular run. Is that correct? The problem with that it only seems to be available for single repositories? I like the ability to have different suites within a project. For example, I am structuring TestRail by having a project per product, but one of our products is made up of two distinctly separate applications, which are governed by the same release, so I want to be able to report on both at the same time. I’d also like a different suite for our automated tests.