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.