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

Adding a new test run configuration to an existing entry


After much effort, I have now finished writing a complex system that creates a new test run with data from all previously entered configurations, along with the new one I want to add. It then deletes the original set. Oh, and there’s a locking system in place, to prevent multiple processes from competing with each other.

This is a terrible solution, and it generates a ton of unnecessary traffic to your servers, but it works. This is a hugely important feature to the API, and after spending so much time developing a workaround, I feel justified in bumping this thread.

(Up next: Alphabetizing runs using the same method. That’s going to be an order of magnitude more server calls…)


Thanks for your feedback! A simpler solution would be to add a new and separate test plan entry via add_plan_entry and leave the other test runs as is. Other than all test runs/configurations would appear in the same entry (group of runs inside the plan), there’s no practical difference (you would still have the same set of test runs).

I hope this helps!



Unfortunately, add_plan_entry does not allow modifying an existing run configuration. This does not work for my org’s needs - We have far too many scenarios that would make it too much effort for my testers to easily parse through without a logical grouping like configurations.


How many configurations/configuration combinations/runs do you have in a typical test plan? If you know the configurations you want to use in advance, you can simply specify the full set of configurations via add_plan or add_plan_entry and you wouldn’t need to add plan entries or configurations separately afterwards. If you need to dynamically add test runs/configurations, adding new entries via add_plan_entry would also work well depending on the number of configurations. If you have many configurations, users can also switch the test plan layout to a more compact version (via the yellow icons in the toolbar) and this provides a much cleaner/better overview for large test plans.

I hope this helps!



I see with TestRail 5.2 the following features have been added to the API:
Added: Support for run/configuration description for add_plan/add_plan_entry/update_plan_entry API methods
Added: Support for adding/updating/deleting configurations via the API (add/update/delete_config_group and add/update/delete_config)

If I understand correctly this does not include updating configurations in an existing plan entry. Is this still on the roadmap?



Hello Kurt,

Thanks for your posting. Yes, that’s correct and this would be independent of the configuration/run management inside a plan and is for managing the configurations themselves (so, to add/update/delete configuration groups and configurations).

You could only add/update/delete configurations in the UI previously (in the Select Configurations dialog) add adding the add/update/delete API methods for configurations was one of the missing pieces of the API.

Regarding your other question: yes, it’s still planned to look into extending update_plan_entry to add support for updating configurations and this is still on our list. update_plan_entry already supports some of the features you can configure in the UI (such as updating the case selection if you haven’t overridden the case selection for the configuration), but it’s definitely planned to cover the same feature set with the API in the future.



Updating the configurations applied to an existing Test Plan via the API would be a great addition to the library that my team and I would love to take advantage of with our automated testing. +1


Hi Christopher,

Thanks for your feedback. This is already partially supported and you can add new plan entries (with configurations) or remove plan entries. Updating plan entries (and the runs/configuration in it) is also already supported to some extent and you can change the properties of the plan entries which is then propagated to the runs/configurations if they use the entry-level settings (case selection, assignee).



Please add my vote to this. With automation environment this feature is really mandatory. Without this support, we need to depend on manual intervention

I started the test run with the below config
fw1: abc
driver1: 123

Now i received one more fw when test is going on. So i will pause the test, update the new firmware and will resume the test. When test is resumed, we should have the ability to add ‘fw2: dfg’ to existing test run.


Hi Tobias,

Would it be possible to get an update on this feature request. I notice that this has been outstanding for quite some time now.

Our engineers would like the ability to use the ‘update_plan_entry’ API to add one config id to existing test plan entry/run.

Please see riyyappan’s earlier post on this thread. Our test engineers are finding this issue to be a show stopper.

Could you please provide us with some guidance / updates.