Not all tests are equally important. A bug in a "change your profile photo" screen is annoying; a bug that lets a payment be authorized twice is a headline. Risk-Based Testing (RBT) in TestCollab helps your team focus testing effort where the danger is greatest, by writing down what could go wrong, scoring how serious it is, and tracing those risks to the tests, requirements, and defects that keep them in check.
What is Risk-Based Testing?
Risk-Based Testing is a simple discipline: identify the things that could go wrong, rank them, and let that ranking guide where you test first and hardest.
In TestCollab, every risk you record gets a score built from two questions:
Likelihood - how likely is this to happen?
Impact - if it does happen, how bad is it?
TestCollab multiplies the two scores to produce a single number called exposure, then sorts your risks from most to least dangerous. You then link each risk to the test cases, requirements, and defects that address it; so you can prove, at any moment, that your biggest risks are actually being tested.
Why use it?
Prioritize with confidence. Test the riskiest areas first instead of treating every feature the same.
Make risk visible. A single Risk Register replaces scattered spreadsheets and tribal knowledge.
Prove coverage. Show auditors, leadership, or regulators that your critical risks are tied to real tests.
Track mitigation. Record how you're reducing each risk and what danger remains after mitigation (the "residual" risk).
For example, this is the difference between "we ran 4,000 tests last sprint" and "every critical risk to customer funds is covered by a passing test." The second statement is the one a regulator wants to hear.
Key concepts at a glance
Risk - one thing that could go wrong (e.g., "Payment authorization bypass under concurrent sessions"). Each risk gets its own ID like RK‑12.
Risk type - the category of risk: Business, Technical, Schedule, Compliance, Security (your admin can customize these).
Likelihood & Impact - the two scored scales. Each value (e.g., Likely, Critical) carries a number.
Exposure - Likelihood score × Impact score. The higher the number, the more urgent the risk.
Exposure band - the colored severity label the exposure number falls into: Low, Medium, High, Critical (these can also be customized)
Status - where the risk is in its life (e.g., Identified → Analyzed → Mitigating → Mitigated). Some statuses count as "closed/resolved."
Owner & mitigation strategy - who's responsible, and the plan to reduce the risk.
Residual risk - the danger that's left after your mitigation is in place.
Coverage - how many of your risks are actually linked to tests.
A worked example
Say your QA lead records this risk on your online banking project:
RK‑12 - Payment authorization bypass under concurrent sessions Likelihood: Likely (score 4) · Impact: Critical (score 5)
TestCollab calculates Exposure = 4 × 5 = 20, which falls in the Critical band (colored red). This risk now sorts to the top of the register, signaling that it deserves your strongest, earliest testing and that it had better be linked to solid test cases.
Who can do what
RBT respects your project roles. At a high level:
Everyone on the project can open and view the Risk Register.
Team members with the right role (e.g., testers) can add, edit, and link risks - optionally limited to only the risks they created.
Administrators configure Risk Settings (statuses, types, scales, bands) and decide which roles get which risk permissions.
How the pieces fit together
A typical RBT workflow looks like this:
Configure your risk scales, types, statuses, and severity bands once (admin).
Capture risks as you discover them.
Score each risk by likelihood and impact - TestCollab computes the exposure.
Link risks to the test cases, requirements, and defects that address them.
Track coverage to spot risks with no tests behind them.
Mitigate and monitor - record your plan and watch the residual risk come down.
Availability
Risk-Based Testing is an Enterprise (plan) feature.