Impact
// Definition
In risk-based testing, impact is the severity of harm if a feature or component fails — measured by factors such as data loss, financial exposure, safety risk, regulatory penalty, or user experience degradation. Combined with probability (likelihood of failure), impact determines the overall risk score and therefore test priority and depth. High-impact areas warrant deep coverage, dedicated exploratory sessions, and tighter regression regardless of how unlikely failure seems. Typical impact categories: Critical (data loss, security breach, service outage), High (major feature broken, revenue loss), Medium (degraded experience, workaround exists), Low (cosmetic or minor inconvenience).
// Related terms
Risk-Based Testing
Prioritising tests by the likelihood and impact of failure — the highest-risk areas get the most coverage, low-risk areas get less. The honest answer to 'we can't test everything before the release date'.
Probability (in risk-based testing)
The likelihood that a feature, component, or scenario will fail in production — assessed from code complexity, change frequency, past defect density, third-party dependency reliability, and team familiarity with the area. In a risk matrix, probability is one axis and impact is the other; multiplying them yields the risk score that determines test priority. High-probability areas (recently changed code, complex integrations, legacy modules with no tests) receive the deepest exploratory coverage. Low-probability, low-impact areas can be covered by a single smoke-test assertion or deferred when schedule is constrained.
Risk
The combination of the probability that something will go wrong and the impact if it does. In software testing, risk analysis drives where to focus coverage: high-risk areas — frequently changed code, complex integrations, high-value user flows, and external dependencies — receive more tests, tighter regression, and dedicated exploratory sessions. Risk is never zero; the goal is to make explicit trade-offs about which risks to mitigate through testing and which to accept given schedule constraints. A risk register documenting known unknowns and accepted risks is a standard QA deliverable in regulated or high-stakes projects.
Severity
A rating of how badly a defect affects the system or users, independent of when it should be fixed. Common levels: critical (system unusable or data loss), major (core feature broken with no workaround), minor (non-critical degradation), trivial (cosmetic only). Severity measures impact; priority measures urgency — a cosmetic bug on the login page might be low severity but high priority for a public launch.