Testing

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).

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.

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.

The ability to link a test artefact — a test case, a defect, an automated check — back to the requirement, user story, or risk that motivated it, and forward to the build and release in which it was verified. Traceability is the foundation of coverage reporting: without it you cannot answer 'which requirements are untested?' or 'which tests would be affected by this change?' Requirements traceability matrices (RTMs) are the most common artefact; CI systems with linked test results provide automated traceability at scale. Regulated industries (medical devices, aviation, financial systems) treat formal traceability as a mandatory release gate — every requirement must be traceable to at least one passing test.