Risk-Based Testing fits neatly into TestCollab's existing roles, so you control who can record, change, and remove risks the same way you control everything else in a project. This article explains the three layers of access and how to set them up.
The three layers of access
Think of risk access in three tiers:
-
Viewing the Risk Register - everyone. Anyone with access to the project can open the register and see the risks. There's intentionally no separate "view risks" permission to hand out: if a teammate is on the project, they can see its risks.
-
Working with risks - controlled by role. Adding, editing, deleting, and linking risks are governed by a Risks permission group you assign to each role.
-
Configuring Risk-Based Testing - administrators only. The Risk Settings (statuses, types, scales, exposure bands) can be changed only by administrators
Keeping these layers in mind avoids the most common confusion: a teammate can see every risk, but what they can change depends on their role, and settings are always admin-only.
Where to set role permissions
Go to your project's Settings → Roles, then create a new role or edit an existing one.
Each role screen is split into collapsible permission groups - expand the Risks group to see the risk options.
The Risks permission group appears when Risk-Based Testing is available on your plan (Enterprise).
The Risks permission group
Inside the Risks group you'll find five checkboxes, plus a select-all row at the top of the section to tick them all at once:
Permission |
What it allows |
|---|---|
|
Add risks |
Create new risks in the register |
|
Edit any risk |
Edit every risk in the project - and link/unlink it to test cases, requirements, and defects |
|
Edit risks only created by them |
Edit and link only the risks that the user has created |
|
Delete any risk |
Delete any risk in the project |
|
Delete risks only created by them |
Delete only the risks that user created |
A note on linking
Linking a risk to a test case, requirement, or defect counts as an edit. So a teammate needs Edit rights to create or remove those links - whether they do it from the risk itself or from the "Linked Risks" tab on a test case. When edit rights are missing, the Edit, Delete, and link/unlink controls simply appear disabled.
