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

Unable to (re)assign test runs to another user AFTER test run creation


During test run creation it is not always known which persons are available for testing. Or available resources change after particular users have been assigned to a test run.

However, after creation of a test run it’s not possible anymore to assign or change a user.


You can assign individual tests in a Test Run. You can do it by individual case or by a filter.

The bottom screenshot is seen in the 3 pane view for a specific case. The first screenshot shows a Testy Run and the drop down to assign cases.


Thank you for your feedback. After trying this, the test run actually does appear in the todo-list tab, but the status in the test run tab remains “unnassigned”


So in the above - this is my To Do after creating a run and assigning myself to 3 tests. The 3 nest to the AUTH - QA test run means 3 tests are assigned to me. The 115 is the remaining tests - all unassigned. If I click on the AUTH - QA link then it takes me to the 3 tests assigned to me.

I then assigned 2 more test to another person and changed the filter on the To Do page to include the second person:

Now it updated the unassigned and shows the graph of the number of cases for each person and it updated the number assigned to 5 (my original 3 + the 2 new ones).


Hi Jasper,

As Brian mentioned (thank you!), you can change the assignments on the run page with the Assign To button. The assignee property on the test run form is only applied to yet unassigned tests (in order not to override previously made assignments). The unassigned number on the Todo page indicates the number of unassigned tests in a run.



Assigning individual test cases addresses part of the issue.

From the planner’s perspective, who works from the test run tab, a test runs main status remains “unassigned” after assigning all individual individual test cases in a particular run

And an unassigned test run with all individual test cases left unassigned only increases the unassigned count on the todo chart, but the test run won’t appear in the todo list.

It seems logical to me to be able to (re) assign a test run as a whole (until one or more individual test cases are assigned)


Hi Jasper,

Yes, the Assigned To property on the test run level is not updated when you assign individual tests in this run. It can only be set on the test run/plan form and this is to a large degree independent of the actual test assignments. Unassigned tests are also included on the Todo page (also in the chart if you check the option) but we will make sure to look into displaying those unassigned tests more prominently on this page and make it easier to distribute the workload across the team.



I very much agree with the original post that it would be nice to be able to assign a test run after it has been created. It seems strange that we can do this when we create it, but can’t change it after the fact. Can this be done via the api perhaps?

If a test run can be assigned, then it should be able to be re-assigned. Or is there something I’m missing here as to why this is not a good idea?




Hi Kent,

Thanks for your feedback. You can simply reassign individual tests or all tests of a run on the run page via the Assign To button:



I vote for this to be a feature Request. This is should be basic functionality and it seems unthinkable to not be able to do


I’m on this page as I’ve run into the same problem.

As test planner/lead, I’d create multiple “skeleton” test plans without knowing yet the resources who would create the test cases; therefore contents of a test run may initially default to contain all.

When resource is determined, I can’t assign a test run. It would be handy that even under the Test Run view, my team can see who is working on a test run. Without this, we have to devise ways to monitor on who is working on what since the tool doesn’t support it.


Hi Jean & Ymmannuelle - I agree this area is long overdue some attention. It’s in scope of some current development and we’ll have this fixed for TestRail 6.0, if not before.