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

Assigning Groups to a Project

I’m new to TestRail. I’ve added users and assigned them to groups but can’t seem to figure out how to assign groups to Project. This seems like an obvious use of Groups and frankly, if you can’t do this, what’s the point in having Groups?



Users are assigned to Groups but Groups are not assigned to Projects. It is geared more toward user function. I think it is to make it more flexible depending on how businesses use Projects and what groups test across projects.

Hi @mvollmer,
with the groups you can grant or remove privileges to more than one user at once.
I didn’t had to maintain it user for user. If new user joined one of the teams, I just added them to the right group. If I had to restrict privileges, I could do so on group level.

Of course this is more useful in bigger organizations having a similar understanding of privileges…


Im not sure I’m following you. The problem is adding two hundred Testers to a Test. I don’t have a problem with privileges.

Users are assigned to groups but groups can’t be assigned to projects is the problem. Therefore, I have to spend hours to assign users to Projects and Test Runs instead of simply assigning a Group to a Test Run?

Well, I can’t check it online, but as far as I remember, it was possible to assign the project access for user-groups as well:

You can’t do so on Test Run level. If a user has the priv to add results to tests within a project, he can do so on every run as long the run is still open.

I’m not sure I’m being clear. As I understand it, for Testers to test, they have to be assigned to a Test Run. If I want more than one user on a Test Run, I have to add each separately. I have 200 Testers who are all in the Group “Tester” but to assign them to a Test Run, I have to add each separately using a multi step process for each Tester. Am I missing something?

OK, just my understanding. You have to separate the privilege to execute tests (add/modify a result) and to assign a test as part of a run to a user.

Privileges are managed on project level (or even system level). In your case all 200 Testers woulld need to have the privilege, either set on user level or via group. By this all 200 Testers may be able to execute the tests of your test run (and all other open runs).

Let’s assume a bigger run with 1000 tests, you would like to manage the execution. Every tester should have it’s own 5 tests to execute, you can assign them to the user. Each user will get 5 tests in it’s ToDo’s, but the assignment doesn’t prevent other users to execute the test from a different user as long he has the priv on project level.
Assignment on Test Run Level is a different thing.

Probably I’m wrong, but that’s how I remember.

The problem I have is the step where I have to link Users to a Test

I have to do this 200 times. Once for each assignee. The obvious answer is to include Groups in the list of assignees.

How would each person in the group know what to test? And how would you prevent more than one person testing the same case?

What to test is driven by the cases selected. In the graphic above, it’s the test cases included in the Orb Retail - Support folder.

I want them all to test the same case. I want this because each user thinks slightly differently and I want them to find and report defects as they do. By having 200 users testing the same case, I have a lot of confidence that they are finding all of the defects.

What person is going to test a specific test case? That is the question and why using a group to assign a raft of tests to is not generally done. Also prevents 2 or more people trying to test the same test case.

It would really be best to Assign the tests run to no one and each tester Assigns themselves a case as they do them.

In the above scenario - each test will have 200 results. Is that what you want?

Kinda. My hope is that they will all pass. But, if a test fails for a specific Tester, then that tester marks it as such and includes notes or screen shots of the failure. We then use that feedback to determine whether the Tester made a mistake or indeed they discovered a defect.

This is how I would approach it then. The 200 testers know who they are and they can see the run. Create the run - assigned to no one. Each tester can print the run to keep track of them or they can export to Excel/cvs. If one tester fails a test they assign it to themselves and set it to failed. They check off the tests on their print/Excel till they are done.

In the 5-6 years my company has used TR (small group) and been in the forums has anyone asked for assigning groups to a test.

TR is certainly geared to individual testers and with all of the IT work I have done over the years - this use case is outside of the norm.

It might be easier to use the API to create 200 runs, one run assigned to each tester but we do not use the API so I really have no idea how difficult this would be.

Using this approach, How would I know how many tested?

About the only way to do that would be the Excel/csv file would be on a shared network and the case is passed/failed in the file. Even with 200 results for 1 test you would nee d way to determine who did/didn’t test.

In thinking about it the ‘best’ would be a run per tester created/assigned via the API but man that is a lot of runs.

Hi @mvollmer,
I’m not sure if you’ve ever heared about Test Management, but your approach isn’t like this.
Just one point to mention: A fool with a tool is still a fool.

A probable way for you is to create a test plan with a one dimension configuration. Create a Run for all your cases and a configration for each of your user (name it like the user).
You will get 200 runs with the same case instances (if you don’t reduce edit them afterwards).
Later you can report on plan level. Although the figures are lousy IMHO.

If you don’t like configuration, you can still re-run an existing run, which will create a fresh copy of your run (nobody say, it has to be used already before). Create manual 199 copies and name them by user - probably as part of a plan.
Or, as mentioned by @BGanger you can use the API as well to create the multiple instances of test runs - isn’t such complicated if you ever have used an API like this.

In general and IMHO only, a lousy test strategy.
Have fun.