| || |
Assigning multiple roles to individuals in QC
I've been in a nwe position for three months. At my old shop, I made it a practice to only assign a single role to a user. At the current employer, they assign people to multiple roles, and they have made the defect workflow very (probably over) complicated, complete with hiding and requiring fields based on role, etc.
This logic is enforced in workflow with long if this role role..then..else if another role.. type logic, so the first role a person have in the logic will determine hoe their defects behave.
Other than the permissions granted on the "groups and permissions" tab, what other reason would a person need to have multiple roles? Am I missing something? I could just make sure one role had all of the access they were looking for.
I'd appreciate your feedback.
Depending on your group, you also can see some modules, or not.
There are several ways to define user groups, but only two make sense (IMHO).
1. For each group, assign permissions for every module. In that case, users usually belong to only one group (this may be amended, for instance if you want to preserve some licenses on the BPT module : you define an additional group that is the only one to see that module and is otherwise equivalent to the Viewer group ; a user could then be in one regular group plus in that group if (s)he can use BPT).
2. One group defines a set of permissions for only one module. In that case, users belong to several groups.
If the definition of a role in your organization encompasses the complete process, you'd use strategy #1. For instance a "tester" cannot define new releases, cannot create or change requirements, can create, change and execute tests, but cannot create test set folders, can create and modify defects based on some defect status, can execute but not define Excel reports, and so on.
If the release management process, the requirement management process, the test management process, the test execution process and the defects management process are disjoint, i.e. each define its roles, activities and artefacts, then you'd use strategy #2. Then each user can be assigned a role in each of these processes.
Defining a group as a set of permissions on all modules and then assigning a user to several groups definitely is a bad thing to do.
Using multiple group e.g. vendor, tester, dev and test management,Project manager,TDAdmin and Viewer roles. All have different sort of permission and sometime overlap with others to accomplish two task so, end up assigning multiple roles to one user-id