...

RBT is built on top of Risk Management and thus the same concepts and principles apply.

Concepts and Terminology

Risk

In general, we can define Risk as the “effect of uncertainty on objectives” (ISO 31000:2018) that can be positive (opportunity) or negative (threat).

...

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

Source

The risk source is the "element which alone or in combination has the intrinsic potential to give rise to risk" (ISO 31000). 

...

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

Criteria

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

...

ers, together 
with the risk analyst, inform values to metrics like 
complexity, cost, size, quality, and others in order 
to find the Risk Exposure (RE) value for each 
functionality

Examples:

• ???

Categories

Risk categories are a way of classifying and grouping risks together.

...

• business
• technical
• operational
• project management
• external
• compliance
• ...

"Types" of Risks

Inherent Risk

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

Residual Risk

Remaining risk, and implicitly residual risk level, after risk treatment actions have been taken.

Exposures

Exposure

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

Residual Exposure

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

Risk Register

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

Risk Management

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

...

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

Risk Management Process

There are a set of activities that are part of the Risk Management Process: Establishing the Context, Risk Assessment, Risk Treatment, Monitoring & Reviewing . Risk Assessment is in turn composed of Identification, Analysis and Treatment.

...

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

0. Estabilishing the Context

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

...

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

1. Risk Assessment

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

1.1. Risk Identification

Risk identification is the process of finding, recognizing and describing risks (ISO 31000). 

1.2. Risk Analysis

Per ISO 31000, it corresponds to: "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."

...

1.3. Risk Evaluation

Per ISO 31000, it corresponds to the "process of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable. Risk evaluation assists in the decision about risk treatment".

...

In the end, users need to decide whether risks are acceptable or tolerable, of 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 natural consequence of Risk Evaluation and it corresponds to the "process to modify risk" (ISO 31000).

...

• Positive Risk (i.e. "opportunity")
  • Enhance (increase 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 it; don't do nothing about it)

3. Parallel, ongoing activities

3.1. Communication and consultation

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

...

First of all, internal and external stakeholders should be consulted, as 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

These are some of the questions we need to answer.

...

"Risk monitoring and reviewing" tries 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.

Risk Management in Jira

There are several apps for Risk Management in Jira.

...

• at the issue level with some custom fields
• or at the project level, using specific issue type

Risk-Based Testing (RBT)

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

...

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

Purpose

The main purpose of RBT is to use risk management principles to adequate testing.

...

• Make a release go/no go decision based on risks
  • sometimes you may need to ship the product sooner, for time or budget constraints
    • RBT can give you visibility of risks, so you can take a go/no go decision "knowing the risk"
  • RBT implicitly explains why certain tests where executed over other ones, and thus eases communication with other stakeholders and avoids discussion on why some tests where not executed at all
• Increased confidence
  • by focused testing on the higher risks (or risky areas/features), RBT ensures that important items are exhaustively tested and import defects are found sooner; thus, product and it's most important items (e.g. features) can be released with a high degree of confidence, while ensuring they meet expected quality goals

RBT at different levels

Risks may be evaluated at different levels:

...

RBT Process

RBT is much more besides selecting what Tests to execute and their order; RBT affects test planning, authoring and execution.

...

1. What and how "things" can affect our project?
   1. Risk Identification
      1. identification of risks to product (e.g. software/hardware) features; this is normally performed by the team and discussed together
      2. risks are identified before implementation starts and are reviewed throughout the development life cycle; new risks can be identified during implementation
   2. Risk Analysis
      1. risks are discussed together in the team (may involve customer)
      2. risks impact and probability are calculated, and thus the related risk level
2. How will he handle it, in the most effective way (i.e. the one that can return most value)?
   1. Risk Evaluation and Treatment
      1. Test Planning
         
         1. using the input from Risk Analysis, the test manager can  ..
         2. define test strategy (e.g. level of testing to perform, techniques to use, environments to choose)
         3. estimate testing effort
         4. define/estimate schedule (target dates, number of testing iterations)
      2. Test Design
         1. specification of the Tests taking the identified risks as input
         2. use more extensive data for data-driven testing if needed, using automated testing/checking
         3. tests are designed to mitigate the risk (i.e. diminish their probability)
      3. Test Execution
         1. perform testing by descending order of risk level (i.e. execute Tests related with higher risks first); experienced testers, with high degree of domain knowledge may provide more valuable feedback 
         2. thoroughly test risky items, using scripted and exploratory approaches
   2. Risk Monitoring and Reviewing
      1. look at items where you assessed the risk and evaluate if you need to take additional measures/treatments ("Are those items having failed tests? Were bugs founds? Are those bugs relevant? Did we found any new risk while testing?")

RBT in Waterfall

In projects following waterfall methodology in their SDLC, RBT can fit as follows.

...

Please note that risk factors are present in all development phases as each one is prone to risks.

RBT in Agile

Projects adopting Agile principles and values releases, software is delivered incrementaly and frequently, highly focused on customer needs and feedback. In Agile changes are welcome and not really tied to "long phases". Both Agile Software Development and RBT have the customer and its (most important needs/concerns) at the center. 

...

1. Risk Identification and Assessment
   1. Release planning (by "business stakeholders" - PO?)
      1. Highest-risk tasks must be placed in the earliest sprints
   2. Sprint planning (by the whole agile team)
      1. Testers can start creating a risk-based analysis by using the stories given for that iteration, identifying the high-risk stories that can be tested on that iteration, and prioritizing the user stories depending on their criticality to the business
      2. Risk’s impact and likelihood can be evaluated using “Risk Poker” (like planning poker)
2. Risk Treatment (by "testers")
   1. During sprint lifetime, by performing more extensive testing on high-risk stories (including for regression testing purposes)
3. Risk Monitoring and Reviewing (by whom?)
   1. During sprint lifetime,(( how??)

"Traditional", RBT and Hybrid RBT approaches

While in "traditional" testing tests are executed in "ad-hoc" way, in RBT risk is used to choose what tests to execute and their order of execution.

...