Risk-based testing
 |
This article has multiple issues. Please help improve it or discuss these issues on the talk page.
|
Risk-based testing (RBT) is a type of software testing that prioritizes the tests of features and functions based on the risk of their failure - a function of their importance and likelihood or impact of failure.[1][2][3][4] In theory, since there is an infinite number of possible tests, any set of tests must be a subset of all possible tests. Test techniques such as boundary value analysis and state transition testing aim to find the areas most likely to be defective.
Contents |
[edit] Assessing risks
 |
This section does not cite any references or sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (October 2011) |
The changes between two releases or versions is key in order to asses risk. Evaluating critical business modules is a first step in prioritizing tests, but it does not include the notion of evolutionary risk.[clarification needed] This is then expanded using two methods: change-based testing and regression testing.
- Change-based testing allows test teams to assess changes made in a release and then prioritize tests towards modified modules.[vague]
- Regression testing brings more added-value to test strategy.[vague] Once changes have been discovered the aim is to assess direct and non-direct impacts on software.[vague]
These two methods permit test teams to prioritize tests based on risk, change and criticality of business modules. Certain technologies[which?] can make this kind of test strategy very easy to setup and to maintain with software changes.[vague]
[edit] Types of Risks
Risk can be identified as the probability that an undetected software bug may have a negative impact on the user of a system.[5]
The methods assess risks along a variety of dimensions:
[edit] Business or Operational
- High use of a subsystem, function or feature
- Criticality of a subsystem, function or feature, including the cost of failure
[edit] Technical
- Geographic distribution of development team
- Complexity of a subsystem or function
[edit] External
- Sponsor or executive preference
- Regulatory requirements
[edit] E-Business Failure-Mode Related[6]
- Static content defects
- Web page integration defects
- Functional behavior-related failure
- Service (Availability and Performance) related failure
- Usability and Accessibility-related failure
- Security vulnerability
- Large Scale Integration failure
[edit] References
- ^ Gerrard, Paul; Thompson, Neil (2002). Risk Based E-Business Testing. Artech House Publishers. ISBN 1580533140.
- ^ Bach, J. The Challenge of Good Enough Software (1995)
- ^ Bach, J. and Kaner, C. Exploratory and Risk Based Testing (2004)
- ^ Mika Lehto (October 25, 2011). "The concept of risk-based testing and its advantages and disadvantages". Ictstandard.org. https://www.ictstandard.org/article/2011-10-25/concept-risk-based-testing-and-its-advantages-and-disadvantages. Retrieved 2012-03-01.
- ^ Stephane Besson (2012-01-03). "Article info : A Strategy for Risk-Based Testing". Stickyminds.com. http://www.stickyminds.com/s.asp?F=S7566_ART_2. Retrieved 2012-03-01.
- ^ Gerrard, Paul and Thompson, Neil Risk-Based Testing E-Business (2002)
 |
This software engineering-related article is a stub. You can help Wikipedia by expanding it. |
