Risk-based testing (RBT) is a type of software testing that functions as an organizational principle used to prioritize the tests of features and functions in software, based on the risk of failure, the function of their importance and likelihood or impact of failure.[1][2][3] In theory, there are an infinite number of possible tests. Risk-based testing uses risk (re-)assessments to steer all phases of the test process, i.e., test planning, test design, test implementation, test execution and test evaluation.[4] This includes for instance, ranking of tests, and subtests, for functionality; test techniques such as boundary-value analysis, all-pairs testing and state transition tables aim to find the areas most likely to be defective.
Lightweight risk-based testing methods mainly concentrate on two important factors: likelihood and impact.[5] Likelihood means how likely it is for a risk to happen, while impact measures how serious the consequences could be if the risk actually occurs. Instead of using complicated math, these techniques rely on simple judgments and scales.[6] For instance, a team might rate the chance of risk as high, medium, or low and its impact as severe, moderate, or minor. These ratings help prioritize where testing efforts should be focused.[7]
Heavy-weighted risk-based testing is a method used to test software by focusing on the areas where problems are most likely to happen. The testing team looks for the most important parts of the software that might fail and concentrates on testing those parts more thoroughly.[citation needed]
There are four main types of heavy-weight risk-based testing methods:[7]
Risk can be identified as the probability that an undetected software bug may have a negative impact on the user of a system.[8]
The methods assess risks along a variety of dimensions:
[9]
Some considerations about prioritizing risks is written by Venkat Ramakrishnan in a blog. [10]
This software-engineering-related article is a stub. You can help Wikipedia by expanding it.