...

But what is Risk, Risk Management and Risk-Based Testing after all?

Lets Let's start by with the basic concepts.

Concepts and Terminology

...

We can also look at it as an uncertain event with a positive or negative effect on the measurable success-criteria of a project.

Therefore, and as a way to overcome a common misconception, risks are not always negative; however, many times we may be more focused on these ones. 

...

• dependency on unsupported open-source library
• dependency on a closed, proprietary library without access to source-code 
• replacement of relational database with a NoSQL one
• lack of sample data
• inability to thoroughly verify/discuss requirement requirements with customer
• new technology, never used before
• lack of skills within the team

Level of Risk

The level of risk, sometimes just simply called "risk value" or "risk," , can be defined as a combination of the probability/likelihood and the impact/consequence of an event on the objectives.

...

It can be defined as a percentage, a number interval (e.g. 0-4) or as a ordered list of values (e.g. "low", "medium", "high", "very high."). 

Probability can be evaluated using multiple weightned weighted criteria/factors (e.g. software maturity, software complexity, type of change, number of changed components, related defect rate, etc).

Impact / Consequence

Outcome The outcome of an event affecting objectives. In other words, it can also be defined as the overall loss or revenue that could occur IF the risk occurs.

...

• Can be positive (i.e. an "opportunity") or negative (i.e. ”threat”)
• Can be evaluated using multiple weightned weighted criteria
  • frequency of use, number of affected users, category/significance of affected users, type of impact, etc

...

Thus, if the probability of an event is 0, that risk won't happen. Likewise, a risk with no impact also leads to a risk score of 0.

Having an a high-impact risk by itself may be is not something not to worry much about unless the probability of the associated event is "high" enough.

Impact may be defined as a number interval (e.g. [0-4]) or as a ordered list of values (e.g. ["low", "medium", "high", "very high"]). 

...

• unclear requirements
• external library
• external stakeholder
• regulatory constraints
  
• adoption of new process 
• ...

Criteria

Risk criteria corresponds correspond to the "terms of reference against which the significance of a risk is evaluated" (ISO 31000).

"Criteria can be imposed by, or derived from, legal and regulatory requirements and other requirements to which the organization subscribeorganization subscribes."

This risk criteria includes the definition of multiple levels for the probability and impact variables. 

...

"Types" of Risks

Inherent Risk

Existent Existing risk, and implicitly implicit risk level, before any treatment actions are taken.

...

Although not part of ISO 31000, "exposure" is commonly used to refer a the categorization (e.g. "low", "medium", "high", "severe") of the risk based on its level. Sometimes it's also use used as a synonym for the calculated risk level value, so please be aware of it.

...

Residual exposure corresponds to the exposure after treatment, based on the remaining residual risk. Sometimes it's also use a synonym used as a synonym for the calculated residual risk level value, so please be aware of it.

...

The Risk Register is used to store and document risks along with the risk treatment responses. It is an essential tool for assisting on with the risk management activities that can give visibility of current risks, and help on in the process of documenting and reviewing them.

...

Risk Management corresponds to the "coordinated activities to direct and control an organization with regard to risk.".

All organisations organizations and projects are subject to risks , of many different categories , that may or not happen and , if so, may impact on the defined objectives.

The purpose of Risk Management is to have a systematic approach to address risks effectively by having the defined objectives in mind, by taking advantage of them in case they're there are opportunities that benefit our objectives, or by minimizing threats that may impact negatively on what we foresee to achieve.

...

The overall process starts by establishing the context, so users have a common understanding on of the objectives, on the internal/external "constraints" and agree on the definition of risk criteria.

After that, users will identify and describe the risks, analyze them as a means to obtain its their characteristics (e.g. risk level), and decide what actions (i.e. treatments), if any, to take depending on the latter.

Monitoring and reviewing of risks is an ongoing activity that provides a feedback loop to the whole Risk Management Process, to depict changes on in context, risk criteria, risks themselves and related treatments.

0.

...

Establishing the Context

The foundation of the Risk Management Process is establishing the context.

The context Context provides information about the objectives that need to be pursued and also the internal and external environments or contexts that be are involved.

Part of setting the context is the definition of risk criteria itself, based on the internal and external contexts and on the objectives to be pursuepursued.

1. Risk Assessment

Risk assessment corresponds to the overall process of performing risk identification, analysis and evaluation (ISO 31000).

...

Per ISO 31000, it corresponds to the: "Process to comprehend the nature of risk and to determine the level of risk. Risk analysis provides the basis for risk evaluation and decisions about risk treatment. Risk analysis includes risk estimation."

In other words, and oversimplifying it a bit, the purpose of this activity is to assess the event probability/likelihood and impact for the identified risks. This may involve answering a set of well-defined weightned weighted questions to find out their value.

...

Probability and Impact can be defined as integers with a limited range (e.g. 0-4). By having a very limited range for the values, it makes the process more manageable and easier to perform.

After having agreed on the risk's probability and impact, The the same principle can be applied to the calculated risk level which we may categorize by truncating it to something similar to, for example:

...

If you segment the calculated value or not, and how you do that, is a bit more or less up to you.

This is an example of a risk matrix with the calculated risk levels. You may also use colours to quickly depict the higher risks.

...

In the end, users need to decide whether risks are acceptable or tolerable, of or if they want to modify them instead by treatment measures. As an example, you may decide to apply treatments only on risks categorized as "high," , "very high" or "severe.".

2. Risk Treatment

Risk Treatment comes as a natural consequence of Risk Evaluation and it corresponds to the "process to modify risk" (ISO 31000).

...

Whenever acting on a risk, users can apply one or more of the several possible response strategies (i.e. treatments,) , depending on the nature/consequence of the risk (i.e. positive or negative risk.).

...

• Positive Risk (i.e. "opportunity")
  • Enhance (increase the probability of happening)
  • Share (allocate some/all ownership to a third party)
  • Exploit (ensure opportunity is realized)
  • Accept (leave it as-is and simply take advantage of it, if and when it happens)
• Negative Risk (i.e. "threat")
  • Mitigate (reduce probability of happening)
  • Transfer (transfer it to a third party entity, which may leave some residual risk though) 
  • Avoid (remove/eliminate risk source)
  • Accept (acklowledge acknowledge it; don't do nothing anything about it)

3. Parallel, ongoing activities

...

"Communication and consultation with external and internal stakeholders should take place during all stages of the risk management process."

 Communication should happen continuously in order to leverage other activities.

First of all, internal and external stakeholders should be consulted, as a means to establish the context (or reviewing it later on.) . However, all of them are invited to provide feedback on the remaining activities as projects/systems and risks evolve in a dynamic.

3.2. Risk Monitoring and Reviewing

...

• Can a risk be closed?
• Did the impact or likelihood change?
• Have new risks arisearisen?
• Did any of the contexts change?
• What have we learn learned from past events? Are we actively analyzing them?

"Risk monitoring and reviewing" tries try to answer the previous questions; it can be seen as an active surveillance over the whole process as means to ensure that we're effectively on control.

...

However, they follow different approaches for to handling risk. 

Some of them perform Risk Management...

...

RBT (Risk-Based Testing) is a testing strategy that follows the principles of Risk Management but in a testing context.

In software development projects, or in any development project in general, there are a set of common objectives among other onesthese are:

• "quality" 
•  cost control
• time-to-market (i.e. target release/delivery dates)

These goals can be affected by risks coming from different sources (internal or external,) , due to all sorts of factors. In case of negative risks, the risk level will depend on things such as the complexity of the change, number and kind of impacted users, frequency of usage, likelihood of failure, etc.

...

Quality is a broad word embracing "fit" of the product to customer needs and many quality attributes (i.e. "quality properties" as per ISO/IEC 25010:2011), which risks may affect. Intrinsic An intrinsic part of quality is ensuring that a product has few bugs (or at least reduce the a reduced probability of bugs on important/risky areas).

If testing is performed as a means to find/avoid bugs, RBT can be used as a "mitigation", or even as a an "avoidance" , strategy.

On the other hand, testing is also about understanding, discovering and providing valuable feedback that can help build "better" features and better products. In that sense, RBT may be used to perform thoroughly thorough testing or doing it more lighter/roughly depending on the risk. 

Thus, RBT can be seen as a strategy that uses risks as means to for adequate testing (depth and priority) in order to maximize testing goals. It will affect all testing activities (e.g test planning, design, execution).

Therefore, RBT assists on taking in making testing related decisions based on the assessment of risks.

Purpose

...