Page History

...

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

First of all, it provides a framework for clear communication and discussion of risks, by defining terms and a common language; it also makes risks visible and actionable.

RBT covers customer needs and also the needs of the development team needs, using risks as the input to support testing activities.

Customer Customers are mostly concerning concerned about business features, timing, visible quality and costs.

Development The development team has similar concerns; however, it sees quality in a broader scope as it has to maintain and possibly evolve with the product being developed. Timing and costs need to be managed effectively to be on a budget and avoid delays; however quality must not be hurt and if decisions need to be taken to meet timing/costs criteria, RBT can provide the means to ensure that focus will be given to the features/issues that matter most to customers.

Both customers and the development team want to avoid important defects, thus RBT focus testing effort in focuses the testing efforts on what matters most , on - where we can get most value from.

Overall, RBT's purpose and benefits can be sumed summed up as:

• Focus more on the customer
  • test more thoroughly what customers are more most concerned with
    
    • deliver what is most important to for the business
• Reduce the probability and impact of negative risks
  
  • by focusing testing on higher, negative risks, probability of missing important defects lowers and therefore the probability assigned to the risk lowers as its corresponding risk level; on the other hand, as testing also provides feedback to the team including its developers, the impact of a certain risk may be also decreased also decrease as the feature being worked out may be done differently /or better
• Increase confidence
  • RBT can help on finding find more important defects first, by focused focusing testing on higher risks (paper)
  • by focused testing on the higher risks (or risky areas/features), RBT ensures that important items are exhaustively tested and important 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
• Optimize QA effort and cost
  • RBT can answer questions such as...
  • • What should we test? Everything? But we don't have time...
    • Where should I start from?
    • When can we stop testing? We have to make the release and move on...
    • Can we reduce the testing effort somehow? How and at what "cost"?
    • If we have more time for testing, what is the best way to take advantage of it?
  • RBT provides the means to define the testing scope, focusing on what is relevant, by identifying what tests to execute and their execution priority, given time and resource constraints; the overall amount of test cases may be reduced as not everything needs to be tested or be tested in the same depth 
  • RBT provides a way (based on risks) to choose tests for regression testing
  • RBT provides some clues for selecting candidates for automation
• Increase risk level of positive risks
  • If an opportunity is identified, RBT can be used to provide thoroughly thorough testing and take advantage of it. If a feature is being implemented and if the team finds that making it slighter differently, perhaps by generalizing it further , for examplem or making it more visible, it can increase the probability of the positive risk happen, as end-users may start using it for additional scenarios and thus increase the product added value. Using testing as a constructive feedback loop, knowing the opportunities and their relative relevance, can increase the likelihood, impact and the overall risk level for opportunities

• 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 can be used to overcome risks that block "acceptance" (i.e. customer acceptance of the release)
  • RBT implicitly explains why certain tests where were executed over other ones, and thus eases ease communication with other stakeholders and avoids avoid discussion on why some tests where were not executed at all

RBT at different levels

...

Many teams perform RBT identifying and evaluating risks at "requirement"/Story level: thoroughly testing is performed on risky "requirements", while less riskier risky "requirements" are tested in a more pragmatic way.

...

RBT Process

RBT is much more besides than 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 we handle it , in the most effective way (i.e. the one that what can return the most value)?
   1. Risk Evaluation and Treatment
      1. Test Planning
         
         1. using the input from Risk Analysis, the test manager can...
            1. define test strategy (e.g. level of testing to perform, techniques to use, environments to choose)
            2. estimate testing effort
            3. define/estimate schedule (target dates, number of testing iterations)
      2. Test Design
         1. specification of the Tests taking the identified risks as input; tests are designed to mitigate the risk (i.e. diminish their probability)
         2. make use of more extensive data with data-driven testing and automated testing/checking, if needed
      3. Test Execution
         1. perform testing by descending order of risk level (i.e. execute Tests related with to higher risks first); experienced testers, with a 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 foundsfound? Are those bugs relevant? Did we find any new risk while testing?")

...

In projects following waterfall, or one of the waterfall variants, in their SDLC, RBT can fit as follows followed: (high-level, simplified overview).

1. Risk Identification & Risk Assessment
   1. BAs together with the team discuss risks on in the ”Requirement Analysis” phase 
2. Risk Treatment
   1. performed by testers, during the “Testing” phase
      1. Test Planning takes the inputs input of Risk Assessment to define the testing strategy and effort; the testing scope is agreed
      2. if adopting the scripted testing approach, testers start by exhaustively detailing exaustively test cases for the most risky itemriskiest items, during Test Design
      3. testers will perform more in-depth testing on the risky items during Test Execution
      4. if important bugs are found on the risky items, the software can go back to "Implementation" phase as-soon-as-possible
3. Risk Monitoring and Reviewing
   1. throughout the project development life cycle; special focus is given at testing closure, t 

Please note that even though you may be doing Risk Identification and Assessment on the first phase (i.e. "Requirement Analysis,") , risk factors are present in all development phases as each one is prone to risks.

As your development project goes through different stages sequentially, problems found at a later stage of the pipeline can can lead to rolling back to a previous phase; thus, it can go from Test Execution back to Test Planning... or from the "Testing" high-level phase back to "Implementation"... or even from "Implementation" back to "Design" and "Requirement Analysis.

...

In projects adopting Agile principles and values software is delivered incrementaly incrementally and frequently, being and 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 their most important needs/concerns at the center. 

...

While in "traditional" testing, tests are executed in "ad-hoc" way (without any special criteria/order), in RBT risk is used to choose what tests are to execute be executed and their order of execution.

RBT also conditionates conditions how testing is done (and how test cases are specified): focus is given to tests associated, directly or indirectly, with and higher risk.

In Hybrid RBT, non-risk-based Tests (i.e. tests specified without considering risks) are executed by the risk descending order.

...